The Five Questions

The Blank Whiteboard

"Design a URL shortener." The marker is in your hand. The interviewer waits.

The worst thirty seconds in system design aren't caused by missing knowledge: they're caused by having no procedure. Knowledge without an entry point just swirls. What separates calm candidates from panicked ones is rarely how much they know; it's that the calm ones have a fixed sequence of questions they ask every single time, so the blank whiteboard is never actually blank.

This course is organized around that sequence. Five questions, asked in order, each one surfacing problem shapes, each shape pointing at patterns. The questions are the compass from the last lesson, and the modules of this course are, quite literally, the questions' answer keys.

One thing before the five: get the numbers first. Ask about scale (users, requests per second, data size), about read/write mix, and about what "down" costs. Ten seconds of requirements-gathering, because every question below changes its answer at 100 users versus 100 million: the next lesson is entirely about doing that arithmetic fast.

Question 1: How Does Data Move?

Who talks to whom? For each arrow: is anyone waiting on the answer? Is it a job to do once, or a fact everyone should hear? Does it cross into another company? Does anything stream?

This question draws the arrows of your diagram, and every arrow is a decision: phone call, to-do list, announcement, or ticker. Answered by Module 2 (Moving Data): request-response as the default, escalating to queues, pub/sub, webhooks, and streams only when waiting is wasteful or impossible.

One-line example: "Order confirmation must be instant (call); fulfillment can lag (queue); five teams want to know (announcement)."

Question 2: Where Does Data Live?

What's the source of truth? How big does it get, and how fast does it grow? What's the read/write mix? Does history matter, or only the present?

This question places the heaviest boxes. Answered by Module 3 (Storing Data): replicas when reads outgrow one machine, shards when writes or size do, a smarter routing rule when the shard count must change, and the log-shaped patterns (WAL, event sourcing, CQRS) for durability, history, and shape conflicts.

One-line example: "Orders are ledger-shaped: history matters, disputes happen: store events, not just state."

Question 3: How Is It Served Fast?

Which reads repeat? What's each data type's staleness budget: how old is too old? What's the hit ratio likely to be, and what happens when the hot copy expires?

This question decides what gets a fast copy and how the copy stays honest. Answered by Module 4 (Serving Data Fast): cache-aside as the default, the write-side variants for hot counters, and stampede defenses for the herd moments. The whole module compresses into one move: assign every data type a staleness budget, then pick the machinery that enforces it.

One-line example: "Descriptions: an hour stale is fine. Prices: seconds, with invalidation. The checkout price: zero: read the source."

Question 4: What Happens When It Fails?

For every arrow drawn in Question 1: what happens when the far side hangs? When it fails once? When it fails for ten minutes? Can a retry double something? And the question juniors forget: what does the user see instead?

This question is where designs earn trust, and where interviews are won. Answered by Module 5 (Surviving Failure): timeouts to make hangs visible, retries for weather, idempotency so retries can't double-charge, breakers for climate, bulkheads for hogging, and graceful degradation for the question nobody answers until asked: what does the user get instead of an error?

One-line example: "If the payment provider browns out: timeout at 2× its p99, retry with idempotency keys, break after sustained failure, and degrade to saved-cart-plus-email."

Question 5: How Does It Grow?

If traffic 10×'d next quarter: what runs out first: read capacity, write capacity, storage, or one hot key? What scales by adding machines, and what needs redesign?

This question pressure-tests everything decided so far. Answered by Module 6 (Growing Under Load) and refined by everything after it: load balancing, auto-scaling, and the honest accounting of what horizontal scaling can and can't buy.

One-line example: "Reads scale with replicas and cache; writes hit the wall at one primary: sharding by customer ID is the escape hatch, planned before it's urgent."

And the refinements: Modules 7 through 9 sharpen specific answers (agreement between machines, the front door, production operations), and Modules 10 and 11 re-ask all five questions for data pipelines and AI systems, where the answers bend in interesting ways.

The Demo: Five Questions vs the URL Shortener

Watch the procedure produce a design skeleton in five moves.

1. Flow? One write path (submit a long URL, get a short one: a call, user waits, milliseconds) and one enormously read-heavy path (the redirect: a call, but 100:1 reads to writes). Optional: click analytics: facts nobody waits for: fire events at a queue, never in the redirect path.
2. Storage? Tiny rows (two URLs and a counter), but billions of them, write-once-read-forever. One primary with replicas goes far; at billions, shard by the short code: which is the shard key and in every query by construction. History? None needed: this is current-state data. Boring tables, proudly.
3. Fast? The redirect is the same answer forever (the mapping never changes): a cache's dream. Cache-aside with a long TTL; hit ratio will be huge because link popularity is skewed... which also means hot keys, so the top links get stampede treatment: they should simply never expire.
4. Failure? The redirect must basically never fail: cache misses fall to replicas; a full cache restart is the scary scenario, so there's a warm-and-ramp plan. Creating links can degrade honestly ("try again shortly") without much harm: the two paths get different reliability budgets.
5. Growth? Reads scale sideways (cache + replicas: add boxes). Writes are light. The real growth question is key generation: random codes need collision checks; a counter-based scheme needs coordination at scale. Named as future work, with the options priced.

Five questions, ~three minutes of talking, and the whiteboard now has: two paths with different profiles, a storage plan with a shard key, a caching plan with a stampede answer, failure budgets per path, and a named growth risk. No memorized diagram: and nothing the interviewer changes can strand you, because the procedure re-runs on any requirement.

Using It in Interviews (and at Work)

• Announce it as your agenda. "Let me work through this in order: data flow, storage, serving it fast, failure, growth." Interviewers relax when candidates show a procedure: it signals you'll cover the ground without being dragged.
• Use it as a gap-checker. Stuck, or suspiciously done early? Re-walk the five. The one you skipped (it's almost always Question 4) is where the follow-up questions were waiting.
• At work, run it on designs you review, not just designs you write. "What happens when this arrow's far side hangs?" is the highest-value code-review question in distributed systems, and it's Question 4 wearing work clothes.

TL;DR Card