A system design interview is not a drawing test, but the drawing is where most people quietly lose it. You start with a tidy box for the client, and thirty minutes later the board is a thicket of crossed arrows, three things labelled "service," and a database you drew twice. The interviewer stops following, and once they stop following they stop being convinced.
The fix is not to draw better under pressure. It is to draw in a fixed order that you have practised, so the picture builds itself while your attention stays on the trade-offs you are talking about. Here is the order that works, and how to make each step take seconds instead of minutes.
The diagram is not the deliverable. The conversation is.
Interviewers are not grading your rectangles. They are watching whether you can take a vague prompt, carve it into components, and reason about what breaks first. The diagram exists to keep that conversation legible: to both of you, in real time. So the goal is a picture that is always readable, never a picture that is finished. If the board is clear at every moment, you can afford to be slow and thoughtful with your words.
That means two rules before you draw anything. Talk while you draw, never in silence. And never redraw; move and extend what is already there. Both get much easier when the tool keeps your arrows tidy for you, which is the whole reason to draw this on a real canvas instead of a shared doc.
Start with the request path
Every design has a spine: what happens to one request from the moment a user makes it. Draw that first, left to right, before you say the word "scale." Client, edge, the thing that answers, the thing that remembers. Five boxes and four arrows, and you already have something to talk to.
Notice there is nothing clever here yet, and that is the point. You have given the interviewer a shared vocabulary. Now every scaling decision is a small, visible edit to a picture you both already understand, instead of a new drawing you have to narrate from scratch.
Scale it live, one bottleneck at a time
The interesting part of the interview is what you add when the numbers get big, and the trick is to add it where it belongs on the spine, saying why as you go. You are not decorating; you are responding to a specific pressure. Walk the request path and ask what falls over first.
- Reads dominate? Put read replicas behind the database and a cache in front of it. Draw the cache as a detour off the API box, not a new stop on the main line.
- Writes spiky? Drop a queue after the API and a worker behind it, so the slow work happens off the request path. Now the diagram shows sync and async as two clearly different shapes.
- One region not enough? Wrap the whole spine in a box, label it a region, and clone it. Suddenly replication and failover have a place to live.
- One table too hot? Split the database box into shards and say a word about the shard key. That single edit carries a whole conversation.
Great system design diagrams are not drawn. They are grown, one visible decision at a time.
Keep it legible while you talk
The reason boards turn into knots is that arrows get drawn as straight lines through whatever is in the way. On a real canvas you can lean on the tooling instead. Use smart connectors so a new arrow bends around existing boxes rather than across them, and the picture stays clean even as it fills. Group the pieces that belong together (the region, the async lane, the data tier) into labelled containers, so the interviewer can see the structure, not just the parts. When you rename a component, do it once and let every reference follow.
None of this is about being fussy. It is about buying back the seconds you would otherwise spend apologising for the mess, and spending them on the answer instead.
Practise the order, not the picture
You cannot predict the prompt, but you can predict the shape of your answer: spine first, then bottlenecks in the order they bite, then a boundary around it all. Rehearse that sequence a dozen times on the same canvas and it becomes muscle memory, which is exactly what you want when the room is quiet and the clock is loud. The candidates who look calm are not drawing faster. They are drawing in an order they have done before.
Open a blank canvas, draw the five-box spine, and start adding pressure. By the third practice run the diagram will keep up with your thinking instead of fighting it.