🎯 Interview & Career · Chapter 4

The system design round: a 6-step framework

You already know the six steps. This lesson is about the clock, the rubric and the interviewer — because most design rounds are lost at minute 25, not at step 4.

Study this lesson free in the app →

The basics

The system design round is a 45–60 minute conversation where you design a data system — “design Meghalaya Cabs' driver payouts pipeline” — on a whiteboard or shared doc, while the interviewer probes your choices.

Builds on sc-003. That lesson taught the six steps: requirements → numbers → interfaces → boxes → deep dive → failure & cost, and why numbers before nouns. This one is about running the round: how to budget the minutes, what the interviewer is writing on their rubric at each step, how to follow when they steer, and what separates a mid-level ‘yes’ from a senior ‘strong yes’.

The mental model: you are the driver of a 50-minute meeting with one stakeholder. Your job is to cover all six steps, go deep on one, check in at every transition, and leave evidence for every rubric line.

Words to know: time-box, checkpoint, rubric, deep dive, steer, level signal.

Explained

Minute 28 of 50. Arjun has a beautiful whiteboard: Kafka, Flink, Iceberg, Airflow, Snowflake, a feature store.

The interviewer: “Let's talk about what happens if a payout runs twice.”

Arjun: “Sure — just let me finish the serving layer first.”

He never got to it. Feedback: “Broad, no depth. Did not engage with correctness when prompted.” He knew the six steps. He lost the clock and ignored the steer.

The architect's site visit

A client asks an architect in Shillong to design a house on a hillside plot. They have one hour on site.

A good architect asks first: how many people, budget, monsoon drainage? Paces the plot. Sketches rooms. Then — when the client says “I'm worried about landslides” — she stops sketching the kitchen and spends twenty minutes on retaining walls and foundations.

She leaves with a rough plan of everything and a detailed plan of the one thing the client cared most about. Breadth to show you see the whole, depth where the client points.

The 50-minute clock

Say the plan at minute 0: “I'll spend a few minutes on requirements and numbers, sketch end to end, then go deep wherever you'd like.” It tells the interviewer you're managing time — itself a rubric line.

What the interviewer is writing

rubric line          evidence they want                     where it comes from
──────────────────────────────────────────────────────────────────────────────
Requirements         asked about freshness, correctness,     step 1
                     consumers; scoped explicitly
Estimation           did arithmetic, drew a conclusion       step 2
                     (‘small — one DB is fine’)
High-level design    coherent end-to-end flow, data model    steps 3–4
Depth                one component in real detail            step 5
Trade-offs           named alternatives + why not            every step
Operability          failure, idempotency, backfill,         step 6
                     monitoring, cost
Communication        drove, checked in, followed steers      throughout

A gap in any line is a risk. The depth and trade-offs lines are where mid and senior candidates separate.

Worked opening: driver payouts

Prompt: “Design the pipeline that computes weekly payouts for Meghalaya Cabs drivers.”

Requirements (spoken): “Who consumes it — finance, who transfers money every Monday? So correctness beats freshness: weekly, but exactly right, auditable, never paid twice. Inputs: completed rides, incentives, penalties, cash collected by drivers?”

Numbers: “~40,000 active drivers, ~1M rides a day, so 7M rides a week — about 12 rides per second on average. Output is 40,000 payout rows a week. This is small data; the hard part isn't scale, it's correctness.”

Boxes: rides + incentive rules → daily earnings ledger (append-only, one row per ride per adjustment) → weekly payout calculation → payout file to bank API with idempotency key driver_id + week → reconciliation against bank confirmations.

Checkpoint: “That's end to end. I think the interesting part is guaranteeing no double payouts and handling late adjustments — shall I go deep there?”

Running the deep dive

Pick the part with the most risk, not the most technology. For payouts that's correctness:

• Idempotency: payout request keyed by (driver_id, week); the bank API rejects a duplicate key, and our payout table has a unique constraint on it. A rerun can't pay twice.
• Late adjustments: a refund for last week's ride arrives Tuesday. Never mutate a paid week — write a negative adjustment into this week's ledger. The ledger is append-only, so every rupee is traceable.
• Cut-off: week closes Sunday 23:59 IST; rides completed after go to next week, by completed_at, not load time.
• Verification before money moves: sum of payouts = sum of ledger for the week; no driver negative beyond a threshold; count of drivers within ±10% of last week. Any failure blocks the file.

Narrate each as choice → reason → alternative rejected: “append-only ledger, because auditors need history; I rejected updating rows in place because we'd lose what was paid.”

How the round is lost

• Overrunning boxes. Still drawing at minute 30 means no depth and no failure discussion — two rubric lines blank.
• Ignoring the steer. “Just let me finish” when the interviewer asks about duplicates. They asked because they need that evidence.
• Deep-diving the easy part. Fifteen minutes on Kafka partitions for a 12-events-per-second system.
• No checkpoints. Ten minutes in a direction the interviewer didn't care about.
• Defending a mistake. “Actually that would double-count” — then fix it. Correcting yourself is scored well.
• Tool-name soup. Each box should have a reason; three boxes with reasons beat eight without.
• No ending. Running out mid-sentence. Keep two minutes for a recap.

Six steps, one clock, one deep dive, follow every steer.

At each transition: summarise, then ask ‘deeper here, or move on?’ Leave evidence on every rubric line.

Words to know

In two minutes

• The six steps from sc-003 are the content; this is the choreography — time-box each one in a 45–60 minute round.
• Rough budget for 50 minutes: requirements 5, numbers 5, interfaces and data model 5, boxes 10, deep dive 15, failure and cost 7, questions 3.
• Interviewers score dimensions, not the diagram: requirements, estimation, design, depth, trade-offs, operability, communication.
• Checkpoint at every transition: summarise, then ask whether to go deeper or move on.
• When the interviewer steers, follow immediately — the steer is pointing at what they still need evidence for.
• For each component, say what you chose, why, and what you'd use if one number changed.
• Senior signal: correctness and failure modes first, cost awareness, and saying what not to build.
• Recover from mistakes out loud; correcting yourself is evidence, defending an error is not.

Test yourself

There are 8 questions, 3 puzzles and 5 recall cards for this lesson in the app — the recall cards come back on later days, just before you would forget.