Software Architecture

Architecture is the set of decisions that are hard to reverse. Choosing a variable name is cheap to change; choosing whether two teams share a database is not. Good architecture keeps the expensive decisions few, deliberate, and aligned with how the organization actually works.

This hub covers architecture at the level of systems and services: styles, boundaries, consistency, and scale. Code-level design (SOLID, design patterns) lives in Software Craft; asynchronous plumbing lives in Messaging & Event Streaming.

TL;DR

• Architecture is trade-offs, not best practices. Every style buys something and costs something.
• Start with a well-structured monolith. Split into services when team or scaling pressure demands it.
• Draw boundaries around the domain, not around technical layers.
• Point dependencies inward. Business rules shouldn't import frameworks or databases.
• Pick consistency deliberately. Strong consistency is simple; eventual consistency scales.
• Write decisions down with architecture decision records.

Architectural Styles at a Glance

Not sure which applies? Start with Monolith vs Microservices.

Featured Topics

System Design

• System Design — Requirements, estimates, and building blocks for large systems
• Scalability — Horizontal vs vertical scaling, statelessness, and bottlenecks
• The Twelve-Factor App — Principles for cloud-ready services

Architectural Styles

• Monolith vs Microservices — Choosing and migrating between them
• Microservices — Service boundaries, communication, and data ownership
• Event-Driven Architecture — Events, choreography, and orchestration
• Local-First Software — CRDTs, sync engines, and offline-first apps

Structuring the Domain

• Domain-Driven Design — Bounded contexts, aggregates, and ubiquitous language
• Clean Architecture — Dependency rule and use-case-centered design
• Hexagonal Architecture — Ports and adapters

Data Consistency Patterns

• CQRS — Separate models for reads and writes
• Saga Pattern — Distributed transactions with compensating actions

Dependencies Point Inward

Clean and hexagonal architecture share this idea: the domain knows nothing about the web framework or database, so either can change without rewriting business rules.

Common Mistakes

🚫 Microservices on day one — You pay the distributed-systems tax before you know where the boundaries are.

🚫 A distributed monolith — Services that must deploy together and share a database give you the costs of both styles.

🚫 Layering by technology — Folders named controllers/, services/, models/ spread one feature across the codebase. Organize by domain.

🚫 Undocumented decisions — Six months later nobody knows why Kafka was chosen. Record decisions and their context.

🚫 Designing for scale you'll never need — Premature sharding and caching add complexity with no payoff.

Learning Path

Beginner

Learn the vocabulary of system design and scalability. Structure one app as a modular monolith.

Intermediate

Apply domain-driven design to find boundaries, and clean or hexagonal architecture inside them.

Advanced

Design event-driven systems with CQRS and sagas, lead migrations from monolith to services, and review other teams' architecture.

Related Topics

• Software Craft — SOLID, design patterns, and code-level design
• Messaging & Event Streaming — The transport under event-driven systems
• Performance Optimization — Making the architecture fast
• APIs & Integration — Contracts between components