The Method
A 7-Step Walkthrough for Any System Design
The order to work in when you’re handed a blank page and a vague problem.
Big Idea
These seven steps are an order of operations, not a checklist of topics. Each one produces something concrete that the next one needs, so a step you named but didn’t finish is a step you skipped. The sequence is what stops a design from being a picture you drew first and justified afterwards.
Walk It
Seven Steps, One Diagram
Step through it. The diagram only gains a box when a step earns it, and the greyed-out pieces are what you have not justified yet.
Nothing yet. The canvas stays empty on purpose, because everything you would draw now would be a guess.
Who uses this, for what, and how many of them are there?
A written split between what the system must do and what it must hold up under: features on one side, scale, latency, and availability targets on the other.
Treating the one-line prompt as the spec. "Design Twitter" is a prompt, not a requirement, and every ambiguity you leave in it becomes a design you can't defend.
Why This Exists
What Goes Wrong Without An Order
Handed a vague prompt, most people start drawing immediately. The diagram arrives before anyone has said how many users there are, and the rest of the discussion becomes a defence of that first picture.
The opposite failure is just as common: designing for a scale nobody asked for. Sharding, multi-region replication, and a message queue, for a system that will serve a few hundred requests a second.
Without an order to work in, the hard parts get skipped silently. Nobody forgets the database, everybody forgets what happens when it dies.
A sequence fixes all three, because each step produces something the next step needs. If a step produced nothing, you skipped it, whether or not you said its name out loud.
The Mechanism
What Each Step Hands The Next
This is the test for whether a step is finished. If you cannot say what it handed forward, it did not happen.
Going Deeper
Where Each Step Lives In The Roadmap
This walkthrough is the map, not the territory. Each step has a concept that does the actual work.
Common Mistakes
Ways This Framework Gets Misused
Drawing the architecture before asking a single question, then spending the rest of the session defending a diagram that was a guess.
Naming capacity estimation without producing a number, which leaves every later decision resting on nothing.
Choosing the database engine from habit rather than from the access pattern the diagram just revealed.
Designing endpoints that mirror your internal components instead of what a caller actually needs to accomplish.
Sprinkling caches, queues, and shards over a design that has no measured pressure anywhere, which buys complexity and stale data with no throughput in return.
Stopping at “we’ll replicate it” without saying what promotes, how failover is detected, or what the user sees during the gap.
Marching through all seven and never looping back, when the whole reason step 6 exists is to send you back to step 3 with better information.
Key Points
What To Carry Out Of This
The order is the point. Each step produces the input the next one consumes, which is why skipping ahead leaves you making decisions without the facts that decide them.
Requirements before diagrams. The prompt is not the spec, and every ambiguity you don't resolve turns into a design choice you can't justify.
Estimates only need an order of magnitude. 200 requests per second and 200,000 are different systems, and arithmetic is how you find out which one you're in.
The access pattern picks the store. That is why database design sits after the high-level diagram rather than before it.
Schemas and interfaces outlive the conversation, because other people build against them. Components can be rewritten quietly, contracts cannot.
Optimisation needs a named bottleneck. A cache with no pressure behind it is a stale copy you pay to maintain.
Redundancy is a claim until you say what fails over and how long it takes. Step 7 is where a design stops being optimistic.
Quiz Review
Check your understanding
Question 1 of 8
You're handed "design a URL shortener" and you can already picture the architecture. Why is drawing it the wrong first move?
- ✓Because the diagram you're picturing answers a problem nobody has stated yet. Is it ten thousand links or ten billion? Do custom aliases exist? Do links expire? Each of those changes the design, and if you draw before asking, you end up defending a picture instead of solving the actual problem. Requirements come first because every later step consumes them.