The design method

A system design, in an interview or a design review, is a conversation with a deadline. The common failure is not a bad architecture. It is a good architecture for a problem nobody asked about, drawn in such detail that there was no time left to discuss the part that would actually break.

A method fixes that. Not because it makes you cleverer, but because it puts the decisions in an order where each one has what it needs from the one before.

#The five phases

clarify. Ask until you can write down what the system must do and how well. A design built on an unasked question is a design for a different problem.

←

→Play1 / 5

The minutes are a budget for a 45-minute interview, not a rule. What matters is the proportion: about a fifth of the time before any box is drawn, and the largest share on the deep dive. Most weak designs invert that — five minutes of requirements, thirty of boxes, and nothing left for the hard part.

#Clarify: requirements in two lists

Every prompt is ambiguous on purpose. "Design a URL shortener" does not say whether links expire, whether they can be customised, how many there are, or whether analytics matter. The first job is to turn the prompt into two written lists.

Functional requirements — what the system does:

• Create a short link for a long URL
• Redirect a short link to its URL
• Links do not expire; custom aliases are out of scope

Non-functional requirements — how well it must do it, and these are the ones that choose the architecture:

• Redirects are fast — a person is waiting on each one
• Redirects are far more common than creations
• A short link must never point at the wrong URL; brief unavailability is better than a wrong redirect

Notice the last line. It is a consistency-over-availability decision, made in plain language in minute three, and it will decide the design of the data store in minute twenty-five. Non-functional requirements stated that concretely are what make later decisions arguable rather than matters of taste.

Say what is out of scope, out loud. "I will not design analytics" is a decision the interviewer can disagree with now, rather than a gap they find at the end.

#Estimate: only the numbers that choose something

The capacity estimation lesson covers the arithmetic. In the method, the discipline is to compute only the numbers that change a decision:

• Peak requests per second, split into reads and writes. It decides whether one database suffices.
• Data size over the retention period. It decides whether the data fits on one machine.
• The read-to-write ratio. It decides where caching goes and whether replicas help.

State every assumption before using it, and round aggressively. "About 1,000 writes a second" is precise enough to choose an architecture, and anything more precise is a number you invented.

#Sketch: complete before detailed

Draw the whole request path for each functional requirement, at the coarsest level that is still true: client, load balancer, service, data store, and whatever the requirements clearly need. Then write down two things most sketches skip:

• The API — the handful of calls, with their inputs and outputs. It forces the requirements to become concrete.
• The data model — the main entities, their keys, and the one or two queries each must serve.

An end-to-end sketch that is simple is worth far more than a detailed one that stops at the load balancer. You can deepen any part of a complete design; you cannot defend half of one.

#Deepen: where the estimate says it breaks

Now use the numbers. The estimate told you which component carries the most load or holds the most data; that is where to go deep. For a URL shortener it is the redirect read path and the generation of unique short codes. For a feed it is fan-out. For payments it is the duplicate request.

For each deep dive, cover:

• how it works at the estimated scale, with the building block named — a cache, replicas, partitioning, a queue
• what it costs: the staleness of the cache, the lag of the replica, the query that no longer works across partitions
• what happens when it fails

This is the phase an interviewer is actually scoring, and the phase that decides whether a real system survives launch.

#Defend: trade-offs and the condition to revisit

End by stating the decisions that mattered in the form the trade-off lesson teaches: we chose X, it costs Y, we accept that because Z, and we would revisit if W. Then the failure modes — what happens when the database, the cache, or a whole zone disappears.

A design that ends with its costs stated is more convincing than one that claims to have none. Every real design gave something up; saying what shows you know where.

#Using it outside an interview

The same order works for a design document at work, stretched over days instead of minutes: requirements agreed before a diagram exists, estimates attached to assumptions someone can challenge, the deep dives on the parts that will actually carry load, and a section of trade-offs and rejected alternatives.

The worked designs on the System Design page follow exactly this order — requirements, estimation, API and data model, components, decisions with their costs, bottlenecks, failures, scaling — and are the fastest way to practise it: read the brief, run the method yourself, then compare.