interviewfundamentals

What to draw first in a system design interview

Most candidates lose the room in the first ten minutes by drawing the wrong thing. Here is the order that keeps the whiteboard legible and the interviewer following you.

Raiyan MemonSr. Full Stack Developer & Team Lead20 August 20268 min read

Most candidates lose a system design interview in the first ten minutes, and almost always the same way: the interviewer finishes reading the brief, and the candidate starts drawing boxes.

Forty minutes later there is a whiteboard covered in Kafka, a service mesh, three databases and a Redis cluster, and no one in the room — including the candidate — can say what the system does. The design is not wrong exactly. It is unreadable, and an unreadable design cannot be defended, which means it cannot be scored.

The fix is an order of operations. Here it is.

Minutes 0–5: do not draw anything

The first five minutes are for questions, and every one of them is worth more than a box.

What are we actually building? Restate the brief in one sentence and get agreement. "So: users paste text, get a short link, and anyone with the link can read it back." If your one-sentence version is wrong, you want to find out now rather than at minute thirty.

Which two or three things does it have to do? Not ten. Interviewers do not want feature completeness, they want scoping — and choosing what to leave out is itself a graded signal. Say what you are cutting: "I'll leave editing and user accounts out unless you want them."

How big? Ask for daily active users. This is the number the whole design hangs off, and it costs you one question. (What you do with it is back-of-the-envelope estimation.)

What must never break? Is stale data acceptable? Can a write be lost? This is where the CAP conversation belongs, and it belongs here rather than at minute forty when it turns into a rewrite.

Minutes 5–10: draw the spine

Now draw — and draw the smallest thing that could possibly work. One line, left to right, from the user to where the data rests.

Four boxes in a row: browser, API, paste service, Postgres. — The spine. Boring on purpose: it is the smallest system that satisfies the brief, and everything after this is a justified deviation from it.

Client, entry point, the service that does the work, the thing that stores it. Four boxes. That is the entire diagram at minute ten, and it should be.

This feels too simple, and that feeling is the trap. What the spine actually does is establish a shared reference: from here on, every addition is an edit to something the interviewer already understands. Without it, each new box is a new thing to hold in mind, and by box nine nobody is holding any of them.

It also protects you. If you run out of time — and you will — you finish with a coherent simple system that works, rather than half of a complicated one that does not.

Minutes 10–30: grow it, one pressure at a time

Now add things, but never because they are standard. Add each one because a specific number or requirement from your corner of the board demands it, and say which.

The same four boxes, now with a Redis cache beside the database and object storage beside the service. — The same spine with two additions, each traceable to a requirement: a cache because reads outnumber writes ten to one, object storage because payloads do not belong in a row.

The moves, in the order they usually become necessary:

Pressure	The move
Reads dominate writes	A cache, then read replicas
Large payloads	Object storage, and a URL in the row
Slow work in the request path	A queue and a worker
One machine cannot hold the data	Partitioning, and say the key
Users far from the datacentre	A CDN at the edge
Traffic is spiky	Autoscaling behind the load balancer

Each row is one sentence in the room: "reads are ten times writes, so I'll put a cache here, cache-aside, and accept about a minute of staleness." Requirement, change, consequence. Say all three and you have demonstrated the thing being tested; say only the middle one and you have named a technology.

What not to draw first

Some things are correct additions and terrible openings, because they signal that you are reaching for tools instead of reasoning about the problem:

Kubernetes, service meshes, CI/CD. Deployment, not design. Nobody asked.
Microservices before there is a monolith to split. Splitting is a response to a pressure — team size, deploy independence, a hot path with different scaling needs. Say the pressure first or do not split.
Kafka as the first box. A queue is the answer to "this work does not belong in the request path". If nothing slow has appeared yet, it is decoration.
A sharded database with no capacity estimate. If you have not done the arithmetic, you do not know it does not fit on one node — and it usually does.
The auth flow. Real, important, and worth two sentences of acknowledgement, not ten minutes of OAuth sequence diagram.

Keep the board legible

The diagram is a communication artefact, not a record of your thinking. Some mechanical habits that cost nothing:

Left to right, always. Requests flow one way across the board. The moment arrows start crossing, the reader is spending attention on the picture instead of the design.

Label the arrows, not just the boxes. "Postgres" tells the interviewer nothing they had not assumed. "Write, then invalidate" tells them how the system behaves.

Leave room on the right. You are going to add things. Candidates who start in the middle end up drawing the cache in the margin at an angle.

Do not erase — extend. The evolution from the simple version to the current one is itself part of the answer, and an interviewer who watched it happen has seen you reason.

The order, in one line

Clarify, then estimate, then draw the smallest thing that works, then add one box per pressure and name the pressure.

That is it. It is not clever, and that is the point — the interview is not testing whether you can produce a novel architecture in forty minutes. It is testing whether, handed a vague problem, you narrow it down, size it, build the simple version, and make each complication earn its place. Everyone who can do that under time pressure passes.

The only part that does not transfer from reading is the time pressure. So take a brief you have not seen, set forty minutes, and draw.

Now design it yourself

Draw the architecture on a board and have it graded against the things an interviewer pushes on. Free, and no account needed.