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.
Written for: Mid-to-senior engineers who can build a feature and cannot yet defend a system.
No chapter is published yet. The full contents below is the finished outline; chapters go live as they are written, and none of them will sit behind a signup.
What it makes operable
Outcomes, not topic coverage.
- 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
Complete contents
12 chapters, in order.
Each chapter settles one decision, so it can be read on its own. Read in sequence to build the argument the book is making.
- 01In writing
Start From the Load, Not the Diagram
Shape, peak and growth of traffic, established before a single box is drawn.
- 02In writing
State Is the Hard Part
Why stateless services are easy and the data underneath them is not.
- 03In writing
Choosing a Data Model You Can Live With
Access patterns first; the choice of store is a consequence of them.
- 04In writing
Where to Put the Boundary Between Services
Transaction scope, ownership and deploy cadence, not domain diagrams.
- 05In writing
Caching: Correctness First
Invalidation, staleness contracts, and what a cache is allowed to serve.
- 06In writing
Queues, Backpressure, and Fair Scheduling
What the system does when work arrives faster than it can be finished.
- 07In writing
Consistency You Can Explain to the Business
Choosing a guarantee, then describing it in a sentence non-engineers accept.
- 08In writing
Timeouts, Retries, Idempotency
The three settings that decide whether a partial failure corrupts data.
- 09In writing
Observability as a Design Input
Deciding what you will need to see while the design is still cheap to change.
- 10In writing
Capacity, Cost, and the Bill
Turning a load model into a number the business can plan against.
- 11In writing
Migrating a Running System
Dual writes, backfills, cutovers, and the rollback you keep in reserve.
- 12In writing
Writing the Decision Record
The constraint that forced the choice and the signal that would reverse it.
Evidence
What this book is arguing against.
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.
- 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
Adjacent operating manuals.
Laravel Optimization Playbook
An application that got slower as it got busier does not need a new framework. It needs to be measured, then worked through in a fixed order: the query layer, then write contention, then cache invalidation, then queue saturation, then the runtime. This book runs that order with a measurement at every stage, and ends with the budgets and regression gates that stop the win from decaying the week after you ship it.
Read the full book
Rescuing Broken Software
Walking into a stalled delivery, the temptation is to form an opinion in the first hour and rebuild in the first week. Both are mistakes. This book runs the order that works: reconstruct the real state from the repository, the incident record and the deploy history; stabilise before improving; build a characterisation test net around the paths the business depends on; decide rewrite, refactor or replace with a defensible reason; and renegotiate the schedule before touching the architecture. It ends where a rescue should — with a team that can run the thing without you.
Read the full book