The four-step framework: time budget, scoping and high-level design

The whole round is four steps with a time budget attached. Knowing the budget is most of the value, because the commonest way to fail is to spend the hour unevenly.

This lesson covers the budget and the first half of the hour. Step 1 takes ten minutes and turns three words into a bounded problem. Step 2 takes fifteen minutes and produces a diagram, an API and a data model that together would serve the requirements you wrote down. The deep dive, the wrap-up, and how to talk while doing all of it follow in the next lesson.

The four steps

Five minutes at the start and end are usually eaten by introductions and questions, which is why the budget above adds to 45 rather than 60.

Why the budget is the hard part

Two failure shapes account for most poor results.

Overrunning step 1. The candidate asks fifteen clarifying questions, enjoys the conversation, and reaches minute 22 with no boxes drawn. The design is then rushed, the deep dive never happens, and the interviewer has nothing to score on the two axes that decide level (How you are scored, and how level is decided).

Skipping step 4. The candidate is still drawing at minute 44. The interviewer never hears them critique their own design, which is the single highest-value thing they could have said. Reserve those five minutes even if the design is incomplete.

Watch the clock explicitly

Say the transitions out loud. "That's about ten minutes of scoping — I'll start drawing unless you want more on requirements." This does three things: it shows you manage time, it gives the interviewer a natural place to redirect you, and it stops you drifting.

If the interviewer pulls you off the schedule — and they often will, because they want depth on something specific — follow them. The budget is a default, not a contract. What you should not do is drift off it by accident.

The steps are a loop, not a waterfall

You will return to step 1 during step 3, when a deep dive reveals a requirement you never pinned down. That is fine and expected. Say it: "This makes me realise I never asked whether deletes need to propagate immediately — do they?" Revisiting a requirement deliberately reads as rigour. Discovering halfway through that your design does not meet a requirement you wrote down yourself reads as carelessness.

Step 1: functional requirements as user-facing verbs

Step 1 gets ten minutes and produces a written list that everything afterwards is checked against.

Write functional requirements as things a user or another system can do, in the smallest number that still describes a real product.

For "design a chat system" (Section 14):

• A user can send a message to another user.
• A user can see message history.
• A user can see whether a contact is online.
• The system delivers messages to a user who was offline when they were sent.

Four verbs. Then explicitly park the rest: "I'll treat group chat over 100 members, media attachments, and end-to-end encryption as out of scope unless you'd like one of them in."

Parking is as important as including. It shows you know the surface area, and it prevents the interviewer from assuming you forgot.

Non-functional requirements: the constraints that shape architecture

These decide the design far more than the features do.

For a chat system: latency under a few hundred milliseconds, high availability, messages must never be lost, ordering within a conversation must be stable. Those four sentences rule out a large fraction of possible designs before a single box is drawn.

The question bank

A handful of questions work on almost every prompt:

1. Who uses this, and how many of them?
2. What is the read-to-write ratio?
3. Is this global or one region?
4. How fresh does the data need to be — can a reader see a value a few seconds old?
5. What must never happen? (Lost message, double charge, wrong balance.)
6. What is explicitly out of scope?

Question 4 is the one candidates most often skip, and it decides the consistency model, which decides the storage choice, which decides half the architecture.

The discipline of stopping

Ask five or six questions, not fifteen. When you have enough to design something, stop and say so:

"I have enough to start. To confirm: one-to-one and small group chat, history retained indefinitely, delivery guaranteed, presence in scope, encryption and media out. Fifty million daily users. I'll design for that."

That sentence is a contract. Write it in the corner of the board and refer back to it. If you later drop a requirement — say, you realise guaranteed delivery is expensive — you must say so, not quietly abandon it.

Step 2: draw in this order

With the contract on the board, step 2 gets fifteen minutes. Order matters, because a diagram drawn in the wrong order becomes a tangle that you spend the deep dive apologising for.

1. Client and entry point. Client box on the far left, then load balancer or API gateway.
2. The one service that does the core thing. One box. Resist splitting into six microservices; you can split later if a requirement forces it.
3. The storage it needs. Database, and blob storage if there are large objects.
4. Trace the primary write path end to end, drawing arrows and labelling each one.
5. Trace the primary read path. It will usually differ, and where it differs is the interesting part of the design.
6. Add the supporting pieces the paths demand: cache, queue, worker, CDN. Add each one because a path needed it, never because it belongs on a system design diagram.

Leave room, and say the layout out loud

Use the left third of the board for the client and entry layer, the middle for services, the right for storage. Leave vertical space under the service row — the deep dive will add boxes there and you do not want to redraw.

Keep narrating while you draw. Silence while drawing is dead air, and the interviewer cannot score a box they do not understand: "I'm putting the write path through a queue here, because uploads are bursty and I don't want the burst to reach the database directly."

The API

Three or four endpoints, written as signatures. Not a specification — enough to make the data flow unambiguous.

POST /v1/messages          {to_user_id, client_msg_id, body} -> {message_id, created_at}GET  /v1/conversations/{id}/messages?before={message_id}&limit=50 -> [messages]GET  /v1/users/{id}/presence -> {status, last_seen_at}

Two details worth including because interviewers notice them: pagination by cursor rather than by offset (offset pagination shifts when new rows arrive), and a client-supplied identifier such as client_msg_id that makes a retried request idempotent — the same mechanism the payment system in Section 28 relies on.

The data model

Name the entities, their key fields, and — most importantly — the primary key and the partition key, because that choice determines how the data shards later (Sharding, and what it takes away).

messages  (conversation_id, message_id) -- partition by conversation_id,                                        -- clustered by message_id (time-ordered)          sender_id, body, created_atusers     (user_id) name, avatar_url

Say why: "I'm partitioning messages by conversation, because reads are always 'the last N messages in this conversation' — that keeps one query on one partition." One sentence linking the key choice to the access pattern is worth more than the rest of the schema.