Architecture patterns — monolith, microservices, CQRS, event sourcing

Monolith = one codebase, one deployable unit. Everything (UI, API, business logic, DB access) in a single service. Simple to reason about, simple to deploy, simple to debug. Most startups should start here; most teams below 30 engineers stay here longer than they think.

Modular monolith = monolith internally split into strong module boundaries (clear interfaces, no cross-module DB access). Captures 80% of microservices' decoupling benefit without the distributed-system costs. A criminally under-used pattern.

**Microservices** = many small services, each owning its domain + its data, communicating via network. Benefits: independent deploys, per-service scaling, team autonomy. Costs: distributed-system complexity (network failures, eventual consistency, debugging across services, deployment orchestration). Worth it past ~50 engineers and clear domain boundaries.

CQRS (Command Query Responsibility Segregation): split the write model from the read model. Writes go through a model optimized for business rules (events, aggregates); reads come from a model optimized for queries (flat, denormalized views). Useful when reads and writes have very different shapes.

Event sourcing: instead of storing current state, store the sequence of events that led to it. 'Account.balance = 100' is reconstructed from 'deposit 50 + deposit 30 + deposit 20'. Perfect audit trail, enables time-travel + replay. Added complexity (event schema evolution, snapshots, projections).

**Circuit breaker**: client-side mechanism to stop calling a failing downstream service. After N failures, 'open' the circuit — return error immediately without calling. After a cooldown, 'half-open' a test call; if it works, fully close. Prevents cascading failures across the system.

Rule of thumb: ship the simplest architecture that solves today's problem + has a believable path to the next 10× scale. Don't build for Google when you have 50 users.