🏗 Scale & System Design · Chapter 1

The system design interview: six steps, in order

Nobody fails a system design interview for choosing Kafka over Kinesis. They fail for naming components before computing a single number.

Study this lesson free in the app →

The basics

A system design interview asks you to design a data platform out loud in about 45 minutes — say, "a ride-booking analytics platform". You are graded less on which tools you pick and more on whether every choice is justified.

The problem it solves: most candidates start naming Kafka, Spark and Snowflake within ten seconds. Then the interviewer asks "why streaming?" and they cannot answer, because they never established who needs the data, how fresh, or how much of it there is. A fixed frame stops that happening.

The mental model: numbers before nouns. Work through six steps in order — requirements, arithmetic, interfaces, boxes, one deep dive, failure and cost. Every component you name must point back to a number you computed. If 1M rides a day works out to about 1,000 events per second at peak, a single Postgres can take it — and saying so earns more credit than adding a cluster.

Explained

"Design a ride-booking data platform."

Most candidates start listing technologies within ten seconds. Kafka. Spark. Snowflake. Airflow.

Every one of those might be right, and it does not matter — because nothing has been justified, and justification is the entire thing being graded.

The six steps, and never out of order

The order is the content. Naming a technology before step 2 means you chose it for reasons you cannot state — and the interviewer's next question is "why that and not the alternative?", which you now cannot answer.

Step 1 — the questions that change the design

Ask these before drawing anything. Each one genuinely changes the answer:

How fresh must it be? Daily, hourly, sub-minute? This single answer decides batch versus streaming, and therefore most of the rest.

Who consumes it? Analysts writing SQL, a dashboard, or a model serving live requests?

How much data, and growing how fast?

Does it have to be exactly right, or approximately right quickly? Finance and product analytics have different answers.

What already exists? You are rarely designing on a blank page.

Step 2 — the arithmetic, out loud

1M rides/day
  → 1M × ~8 events (request, accept, start, ..., pay)  = 8M events/day
  → 8M / 86,400                                        ≈ 93 events/sec average
  → peak ~10×                                           ≈ 1,000 events/sec

size: 8M × 2KB      = 16 GB/day  → ~6 TB/year raw
with replicas ×3    = ~18 TB/year
curated (Parquet)   ≈ 1/5 of raw ≈ 1.2 TB/year

Now every later claim has a number behind it.

1,000 events/sec is not big — a single Postgres can take that. Saying so is a strong signal: it shows you can size a problem rather than reflexively reaching for a cluster. The candidate who says "this doesn't need Kafka" and explains why usually outscores the one who adds it.

Where it goes wrong, in one exchange.

Candidate: "I'd use Kafka, Spark Streaming, and Snowflake."

Interviewer: "Why streaming?"

Candidate: "For real-time analytics."

Interviewer: "Who needs it in real time?"

Candidate: "...the business?"

The design may be perfectly reasonable. The candidate is now unable to defend any part of it, and the rest of the hour is spent failing to.

Had they asked step 1 first, they would have learnt finance needs it daily — and a batch design would have been both correct and half the cost.

Numbers that make a difference, worth knowing cold:

1,000 events/sec — one machine. No cluster needed. 100,000 events/sec — now you need partitioning and a real streaming platform. 1 TB — fits on a laptop SSD. Not big data. 1 PB — genuinely distributed, and the cost conversation dominates the design.

And the one people forget: a day of data is usually a rounding error against the history. Backfill and reprocessing volume is often 100× the daily volume, which is what actually sizes your cluster.

Naming technologies in the first two minutes. The most common failure, by a distance.

No numbers. Every claim after that is an opinion.

Designing for scale nobody asked for. Over-engineering reads as inexperience, not ambition.

Ignoring failure. "What if the consumer is down for six hours?" always comes, and it should already be in your answer.

Silence while thinking. They cannot grade what you do not say. Narrate.

No cost. Senior candidates are expected to say roughly what it costs and what they would cut.

Numbers before nouns.

Requirements → arithmetic → interfaces → then boxes → one deep dive → failure and cost.

Every component you name must be justified by a number you computed out loud. If you cannot, do not name it.

Words to know

In two minutes

• System design interviews grade justification, not technology choices.
• Follow six steps in order: requirements, numbers, interfaces, boxes, deep dive, failure and cost.
• Ask about freshness first — daily versus sub-minute decides batch versus streaming and most of the cost.
• Do the arithmetic out loud: events per day ÷ 86,400 = average per second, × 5–10 for peak, × size for storage.
• Know the scale landmarks: 1,000 events/s is one machine, 100,000/s needs partitioned streaming, 1 TB fits on a laptop.
• Backfill and reprocessing volume, not daily volume, usually sizes the batch compute.
• Saying 'this doesn't need Kafka' with numbers behind it beats adding Kafka; narrate, and always cover failure and cost.

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.