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
- 01
Start from a load model instead of a box diagram
- 02
Choose state, consistency and a data model you can still live with at scale
- 03
Make timeouts, retries, idempotency and backpressure explicit decisions
- 04
Write a decision record that names the constraint and the reversal signal
Contents
13 of 13 published
Every chapter is free to read in the browser, cites its own sources, and stands on its own if you came for one decision rather than the whole argument.
- 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 sources
Third-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.
In the age of AI
The advantage was never the model. It's knowing what to build with it — and having a team that can actually ship it.
That's the part I help with: finding where AI genuinely makes your business faster, deciding what's worth building, and standing behind it once it's live.
Four offices, one very full passport
Every dot on this map is a conversation I still remember.
- Where I've spoken
- Office
