status
this chapter is in active development
expect live edits and rapid iteration (except for when i am really busy with other stuff) while this material is written.
the concepts, tradeoffs, and patterns behind building software systems that hold up.
systems design is mostly about tradeoffs. there is no architecture that handles all traffic patterns, no replication strategy that suits every consistency requirement, no deployment model that works for every team. the patterns and principles in the field are starting points, not answers.
this series covers the core vocabulary: how distributed systems fail, what scalability and availability actually mean in practice, and the architectural patterns that come up repeatedly, and why they exist.
core concepts covers the forces that drive every systems design decision: scalability, reliability, availability, the CAP theorem, and the performance-vs-correctness tradeoff that sits under almost everything else.
failure grounds the rest of the series. distributed systems fail differently than single-process programs. partial failures, network partitions, cascading slowdowns. you cannot understand reliability patterns without knowing what they are defending against.
architecture is about what you are optimizing for when you make a structural choice. the monolith is not an antipattern. service decomposition has real costs. event-driven systems exist for a reason.
data covers storage, replication, and consistency, the decisions here have the longest-lasting consequences of anything in the series.
communication is how services talk to each other. the choice shapes coupling, failure modes, and operational complexity in ways that compound over time.
resilience covers the patterns that keep systems running when parts of them fail: timeouts, circuit breakers, bulkheads, rate limiting, graceful degradation.
scale is about what actually limits scale at each layer and how teams address it: finding the bottleneck, load balancing, horizontal scaling, database scaling.
observability closes the loop. you cannot reason about a system you cannot see. metrics, logs, traces, and alerting are how you build that visibility.