Drawing the High-Level Design

Start with the API, not the boxes. Two or three endpoints with their inputs and outputs — POST /posts, GET /feed?cursor=. This forces the data flow to be concrete and gives the interviewer something specific to push on.

Then the data model. Main entities, their key fields, and the relationships. Enough to see which queries are cheap and which need help. If a required query has no index that can serve it, that's the design problem, and you've found it in minute twelve rather than minute forty.

Then one pass, client to storage. Client → edge/CDN → load balancer → API service → datastore. Add only the boxes that a requirement demands. Every box needs a sentence: "a queue here because thumbnail generation takes seconds and the upload response shouldn't wait for it." A box you can't justify is a box the interviewer will ask about, and "for scalability" is not an answer.

Trace one request out loud, end to end. A user posts; here's what's written, in what order, and what the response contains. Then a read. Tracing catches gaps that staring at the diagram doesn't — usually a missing write path or a query with nothing to serve it.

Then, and only then, evolve it. Add caching where the read path is hot, a queue where work is slow or bursty, a replica where reads dominate, fan-out where a write has to reach many readers. Each addition should reference a number from your estimate.

Keep it legible. Six to ten boxes at the top level. If a component is getting complicated, draw it as one box and expand it during the deep dive — that is exactly what the deep-dive phase is for. Label the arrows with the protocol or the payload when it isn't obvious (sync HTTP, async event, batch job); half the interesting questions in a design are about the arrows, not the boxes.

The diagram is the shared artefact for the rest of the round — every follow-up question points at part of it. A diagram drawn depth-first, where one component is elaborate and the rest is missing, can't be evaluated and leaves the interviewer with nothing to probe. Getting a complete happy path down early also means that if you run out of time, you ran out of time with a whole answer on the board rather than a quarter of one.

• Sketch the API and the data model before drawing any boxes; both surface disagreement cheaply.
• Cover the happy path end to end before adding anything for scale or failure.
• Every box gets a one-sentence justification tied to a requirement or a number.
• Trace one write and one read out loud through the diagram to find the gaps.
• Add caches, queues, replicas and fan-out as evolutions, each citing the estimate that motivated it.
• Six to ten top-level boxes; push detail into the deep dive rather than into the diagram.
• Label arrows as sync, async or batch — the arrows are where the hard questions live.