The Five Questions

1. Why You Need a Fixed Procedure

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

The hardest moment in a system design interview is usually not caused by missing knowledge. It is caused by having no procedure. Candidates who stay calm are not the ones who know the most. They are the ones who ask the same fixed sequence of questions every single time. So they always know what to do next.

This course is organized around one such sequence: five questions, asked in order. Each question reveals problems, and each problem leads to patterns from this course. The previous lesson explained how to think in patterns. The five questions tell you where to look for them.

Get the numbers first. Before asking the five questions, ask about scale: users, requests per second, and data size. Also ask about the read/write ratio, and what downtime costs. Every question below has a different answer at 100 users than at 100 million. The next lesson covers how to do this arithmetic quickly.

2. Question 1: How Does Data Move?

Ask: Who talks to whom? For each connection, is anyone waiting for the answer? Is this a task to perform once, or a fact that several services need to hear? Does the call cross into another company? Does any data flow continuously?

This question draws the arrows of your diagram. Each arrow is a decision. The default is request-response. Use a message queue when nothing waits on the work. Use pub/sub when several services need the same event. Use webhooks when the call crosses a company boundary. Use streams when data flows continuously. The Moving Data module covers all of these.

Example answer: "Order confirmation must be instant, so it is a direct call. Fulfillment can lag, so it goes on a queue. Five teams need to know about each order, so we publish an event."

3. Question 2: Where Does Data Live?

Ask: What is the source of truth? How big does the data get, and how fast does it grow? What is the read/write mix? Does history matter, or only the current state?

This question places the databases in your design. Use replicas when reads outgrow one machine. Use sharding when writes or data size do. Use consistent hashing when the number of shards must change over time. When history matters, use the log-based patterns: write-ahead log, event sourcing, and CQRS. The Storing Data module covers all of these.

Example answer: "For orders, history matters because disputes happen. We store the events, not just the current state."

4. Question 3: How Is Data Served Fast?

Ask: Which reads repeat? How stale, meaning out of date, is each type of data allowed to be? What hit ratio can we expect, that is, what share of reads will the cache answer? What happens when a popular cache entry expires?

This question decides what gets cached and how the cache stays correct. The default is cache-aside. Use the write-based variants for frequently updated data. Use stampede prevention for very popular keys. The whole caching module comes down to one step. Decide how stale each type of data is allowed to be. Then pick the mechanism that enforces it.

Example answer: "Product descriptions can be an hour stale. Prices can be seconds stale, with invalidation. The price at checkout must be exact, so it always reads from the database."

5. Question 4: What Happens When Something Fails?

Ask: For every arrow drawn in Question 1, what happens when the other side hangs? When it fails once? When it fails for ten minutes? Can a retry cause something to happen twice? And the question junior engineers most often forget: what does the user see instead?

This question is where designs become reliable. It is also the part interviewers probe hardest. Use timeouts so a hung call fails visibly. Use retries with backoff for short outages. Use idempotency so retries cannot double-charge. Use circuit breakers for long outages. Use bulkheads so one failing feature cannot use up the resources of the rest. Use graceful degradation to give the user something useful instead of an error. The Surviving Failure module covers all of these.

Example answer: "If the payment provider becomes slow, we time out at twice its normal worst-case latency. We retry with idempotency keys. We open the circuit breaker after sustained failures. Then we fall back to saving the cart and emailing the customer."

6. Question 5: How Does the System Grow?

Ask: If traffic grew 10x next quarter, what runs out first: read capacity, write capacity, storage, or one very popular key? What scales by adding machines, and what needs a redesign?

This question tests everything you decided so far. The Growing Under Load module answers it with load balancing and auto-scaling. It also gives an honest account of what horizontal scaling, meaning adding more machines, can and cannot fix.

Example answer: "Reads scale with replicas and caching. Writes are limited by the single primary. Sharding by customer ID is the next step, and we plan it before it becomes urgent."

The remaining modules refine these answers: agreement between machines, the entry point of the system, and production operations. The data and AI modules then re-apply all five questions to data pipelines and ML systems.

7. Example: The Five Questions on a URL Shortener

Here is the full procedure applied to the opening question.

1. How does data move? There is one write path: submit a long URL, receive a short one. There is one very read-heavy path: the redirect. Both are direct calls, with roughly a 100:1 read-to-write ratio. Click analytics is optional work that nobody waits for. So it goes to a queue and never runs inside the redirect path.
2. Where does data live? The rows are small: two URLs and a counter. But there are billions of them, written once and read many times. One primary database with replicas is enough for a long time. At billions of rows, shard by the short code, which is already in every query. History does not matter here, so simple tables are the right choice.
3. How is it served fast? A redirect returns the same answer every time, because the mapping never changes. This is ideal for cache-aside with a long TTL, the time an entry is allowed to stay in the cache. Link popularity is heavily skewed: a few links get most of the clicks. So the most popular links need stampede prevention. In practice, they should never expire.
4. What happens when it fails? The redirect path must almost never fail: cache misses fall back to replicas. Creating new links can fail with a clear message ("try again shortly") without much harm. The two paths get different reliability budgets.
5. How does it grow? Reads scale by adding replicas and cache nodes. Writes are light. The real growth question is key generation. Random codes need collision checks. A counter-based scheme needs coordination across servers, so two machines never generate the same code. Name it as future work and state the options.

This takes about three minutes of talking. The whiteboard now has two paths with different profiles. It has a storage plan with a shard key, a caching plan, failure budgets, and a named growth risk. Nothing was memorized. If the interviewer changes a requirement, you simply run the questions again.

8. How to Use the Five Questions

💡 In an interview, announce the procedure as your agenda: "Let me work through this in order: data flow, storage, caching, failure handling, growth." Interviewers respond well to candidates who show a procedure. It shows you will cover everything without being asked.

Use it as a checklist when stuck. If you are stuck, or finished suspiciously early, go through the five questions again. The one you skipped is usually Question 4. That is where most follow-up questions come from.

Use it at work, too. Run the questions on designs you review, not only designs you write. "What happens when the other side of this call hangs?" is one of the most valuable review questions in distributed systems.

9. TL;DR