Architecture
System Design for Developers
Reasoning about load, state, and failure before you write the code
Almost every scaling problem is a decision made early, cheaply and without evidence, so design is the discipline of forcing load, state and failure into the open and writing down why.
Design is not drawing boxes. It is deciding, in order, what load the system has to absorb, where state lives and what consistency it needs, and how the thing behaves when a dependency is gone, then recording the constraint that forced each answer and the signal that would reverse it. This book works through that order using the decisions that actually cost money later: data model, service boundaries, caching, queues and backpressure, timeouts and idempotency, observability, capacity, and how to migrate a system that cannot stop running.
What it makes operable
- 01Start from a load model instead of a box diagram
- 02Choose state, consistency and a data model you can still live with at scale
- 03Make timeouts, retries, idempotency and backpressure explicit decisions
- 04Write a decision record that names the constraint and the reversal signal
Contents
13 of 13 published- 01Start From the Load, Not the DiagramShape, peak and growth of traffic, established before a single box is drawn.12 min
- 02State Is the Hard PartWhy stateless services are easy and the data underneath them is not.11 min
- 03Consistency You Can Explain to the BusinessChoosing a guarantee, then describing it in a sentence non-engineers accept.11 min
- 04Choosing a Data Model You Can Live WithAccess patterns first; the choice of store is a consequence of them.12 min
- 05Where to Put the Boundary Between ServicesTransaction scope, ownership and deploy cadence, not domain diagrams.11 min
- 06Caching: Correctness FirstInvalidation, staleness contracts, and what a cache is allowed to serve.11 min
- 07Queues, Backpressure, and Fair SchedulingWhat the system does when work arrives faster than it can be finished.12 min
- 08Timeouts, Retries, IdempotencyThe three settings that decide whether a partial failure corrupts data.12 min
- 09Failure Domains and the Blast Radius You ChoseHow many customers one failure is allowed to reach, decided on purpose.12 min
- 10Observability as a Design InputDeciding what you will need to see while the design is still cheap to change.11 min
- 11Capacity, Cost, and the BillTurning a load model into a number the business can plan against.11 min
- 12Migrating a Running SystemDual writes, backfills, cutovers, and the rollback you keep in reserve.11 min
- 13Writing the Decision RecordThe constraint that forced the choice and the signal that would reverse it.12 min
Evidence
2 sourcesThird-party sources behind the book's premise. Every figure in them belongs to the party that published it and is attributed to them in the text.
- Legacy Code Modernization with AI Agents (2026)
Tembo · 2026-06-18 · Vendor engineering · reported
- AI Can Migrate Code. Who Validates That the Business Still Works?
Abstracta · 2026-06-11 · Industry report · reported
Continue through the library
