architecture

architectural decisions are about tradeoffs, not correctness. there is no universally right structure for a service. there is the structure that makes sense for your team size, your deployment requirements, your data model, and your failure tolerance, and there is everything else.

this chapter covers the major structural choices and the reasoning behind them. the goal is not a catalog of patterns. it is understanding why each choice exists, what it costs you, and when the cost is worth paying.

what this chapter covers

the monolith is not an antipattern. it is the default architecture and it has real advantages. knowing when to stay monolithic is as important as knowing when to decompose.

service decomposition is what you are actually doing when you "move to microservices." the questions are: what to split, why, and what it costs you in operational complexity, consistency, and latency.

event-driven architecture exists because synchronous request-response does not compose well when you need loose coupling and resilience. understanding why async exists clarifies what you give up by choosing it.

cqrs and event sourcing are two related patterns that address specific problems: read-write asymmetry and the need for an auditable history. they are often discussed together and earn their complexity in specific contexts.

serverless is a deployment model, not just a hosting choice. it changes how you think about scaling, cold starts, state, and operational overhead, and it bites you in non-obvious ways.