SYSTEM DESIGN:Lesson 4: What Interviewers Want in 45 Minutes

45 minutes. One whiteboard. No Google.

"I knew Redis, Kafka, and microservices. I still failed the interview because I spent 20 minutes drawing boxes without asking what the product actually does."

System design interviews are not trivia tests. Nobody cares if you can recite the CAP theorem definition. They care if you can take an ambiguous problem — "design a ride-sharing app like Ola" — and turn it into a concrete architecture with trade-offs, numbers, and a clear reasoning path.

This chapter gives you a 4-step framework, a minute-by-minute timeline, and a checklist you can practice until it becomes automatic. Use it for every mock interview, every real interview, and honestly every architecture discussion at work.

Drawing boxes in minute two is a bold strategy

The interviewer is not impressed yet. They have not even told you the product name.

The 4-step framework

Four-step system design interview framework

Every system design answer follows the same four steps. Skip any step and your answer falls apart.

Step 1 — Understand the problem (5–8 minutes)

Do not touch the whiteboard yet. Ask questions. Clarify scope. The interviewer is testing whether you gather requirements before writing code — same skill, bigger canvas.

Questions to always ask:

Example — "Design a food delivery app like Swiggy":

You: "Let me clarify a few things before I start."
   "Are we focusing on the customer ordering flow, or also restaurant
    onboarding and delivery partner tracking?"
   → Interviewer: "Customer ordering flow — browse, order, track."

You: "What scale are we targeting?"
   → Interviewer: "10 million DAU, mostly Indian cities."

You: "Is real-time order tracking a requirement, or is 30-second
    refresh acceptable?"
   → Interviewer: "30-second refresh is fine."

You: "Great. I will focus on: restaurant discovery, cart/checkout,
    order placement, and order status tracking. I will defer restaurant
    management and delivery partner routing to keep scope manageable."

That 5-minute conversation just saved you from designing a system that is too broad to finish in 45 minutes. Interviewers reward focus.

Step 2 — Estimate scale (5–7 minutes)

Pull out numbers. This is where the estimation chapter pays off. You need QPS, storage, and bandwidth before you can choose components.

Swiggy-like app:
  DAU: 10 million
  Orders per user per day: 0.5 (not everyone orders daily)
  Browse sessions per day: 3
  Requests per browse session: 20 (restaurant list, menu, photos)

  Orders/day:  10M × 0.5 = 5M
  Browses/day: 10M × 3 × 20 = 600M
  Total/day:   ~605M requests
  Average QPS: 605M / 100K ≈ 6,000
  Peak QPS:    6,000 × 5 = 30,000 (food has sharp lunch/dinner peaks)

Write these numbers on the board. Refer back to them when justifying every component choice. "I am adding a CDN because 80% of our 30,000 peak QPS serves restaurant images" is a sentence that scores points.

Step 3 — High-level design (15–20 minutes)

Draw the architecture. Start simple. Add complexity only when the numbers demand it.

The drawing order that works:

1. Client (mobile app / web)
2. Load balancer
3. API servers (stateless)
4. Database (start with one, add replicas when reads are high)
5. Cache (Redis — add when you mention read-heavy queries)
6. CDN (add when you serve images or static content)
7. Message queue (add when you need async processing)
8. Specialized services (only if the problem demands it)

For the Swiggy example, your board might look like:

Mobile App → CDN (restaurant images)
           → Load Balancer → API Servers (×10)
                                → Redis (menu cache, sessions)
                                → Postgres Primary (orders, users)
                                → Read Replicas (×2, restaurant search)
                                → S3 (image storage)
           → WebSocket / polling (order status updates)

Talk through every arrow. "The mobile app hits the CDN for restaurant photos because 80% of our bandwidth is images. API calls go through the load balancer to stateless servers. Menu data is cached in Redis with a 15-minute TTL because menus change rarely."

API design — sketch the key endpoints:

GET  /restaurants?lat=&lng=&cuisine=     → list nearby restaurants
GET  /restaurants/{id}/menu               → restaurant menu
POST /orders                                → place order
GET  /orders/{id}/status                    → track order

You do not need every endpoint. Four to six key APIs show you understand the data flow without wasting time.

Database schema — sketch the core tables:

users          (id, name, phone, address)
restaurants    (id, name, lat, lng, cuisine, rating)
menu_items     (id, restaurant_id, name, price, image_url)
orders         (id, user_id, restaurant_id, status, total, created_at)
order_items    (order_id, menu_item_id, quantity, price)

Step 4 — Deep dive and trade-offs (10–15 minutes)

The interviewer will pick one area and push you deeper. This is where the interview is won or lost. Common deep-dive topics:

How to handle deep dives:

1. State the problem clearly: "At 30,000 peak QPS, the restaurant search query becomes the bottleneck"
2. Present 2 options: "We could use Elasticsearch for geo + text search, or Postgres with PostGIS"
3. Pick one with reasoning: "I would start with Postgres PostGIS because our search is simple geo-radius queries, and adding Elasticsearch is premature at 10M DAU"
4. Mention what you would do at 10x scale: "At 100M DAU, I would migrate search to Elasticsearch"

The "what would you do at 10x" answer is gold. It shows you think in evolution stages, not just the current problem.

Worked walkthrough: URL shortener in 45 minutes

Swiggy above shows the framework on a complex app. URL shortener is the beginner prompt every interviewer knows — and the same four steps apply. Run this in parallel with Lesson 3 napkin math and Lessons 7–8 until it feels automatic.

URL shortening and redirect flow

Step 1 — Clarify (minutes 0–5)

You: "Walk me through an example — long URL in, short link out,
     click short link, land on original page?"
     → Interviewer: "Yes, like bit.ly."

You: "Scale? New links per day, and redirects vs creates?"
     → Interviewer: "100 million new URLs per day, reads dominate."

You: "Code length? Alphanumeric only?"
     → Interviewer: "7 characters, letters and numbers."

You: "Delete or edit links?"
     → Interviewer: "No — create once."

You: "I will cover shorten + redirect, base62 IDs, high availability
     on redirect. I will mention analytics and rate limiting if time."

Step 2 — Estimate (minutes 5–10)

Write these on the board (from Lesson 3):

Writes: 100M/day ÷ 100K ≈ 1,000/sec avg → ~3,000/sec peak
Reads:  1,000 × 100 = 100,000/sec avg → ~300,000/sec peak
Storage: 100M/day × 365 × 10 yr × 600 B ≈ 220 TB
Shape:  read-heavy → cache + CDN are the design, not an afterthought

Step 3 — High-level design (minutes 10–25)

Draw this top-down:

Create path:  Client → LB → App → Primary DB (counter + base62)
Redirect path: Client → CDN → Redis → Read replica → DB (on miss)

Key APIs:

POST /api/v1/urls     { "long_url": "..." }  → 201 + short_url
GET  /x/{code}                            → 301 Location: long_url

Schema (minimal):

urls (id, short_code UNIQUE, long_url, created_at, click_count)
Index on short_code — redirect path depends on it

Narrate the write path: counter → base62 encode → insert → return. Narrate the read path: Redis first, DB on miss, populate cache, return 301.

Step 4 — Deep dive (minutes 25–40)

Pick one area the interviewer cares about:

Wrap-up (minutes 40–45):

"Read-heavy: CDN + Redis absorb 95%+ of redirects.
 Writes are modest — Postgres primary is fine.
 At 10× scale I would shard by short_code and move IDs to Snowflake."

Same four steps as Swiggy. Simpler boxes. Same discipline: clarify, estimate, design, deep dive.

The 45-minute timeline

Time management is the silent killer in system design interviews. Here is how to allocate your 45 minutes.

The golden rule: never spend more than 5 minutes on any single component unless the interviewer asks you to.

Candidates fail by spending 15 minutes explaining how Kafka works when the problem does not need Kafka. Mention it as a future consideration and move on.

If you are running behind at minute 20:

Skip: detailed database schema, every API endpoint, monitoring setup
Keep: architecture diagram, QPS numbers, one deep dive with trade-offs
Say: "I want to make sure we cover the core architecture and at least
      one deep dive — shall I continue with the high-level design?"

Asking the interviewer for guidance is a strength, not a weakness. It shows communication skills.

The checklist: run this before you say "I am done"

Print this mentally. Every box you can check is a point earned.

Requirements

• [ ] Clarified functional requirements (top 3 features)
• [ ] Clarified non-functional requirements (scale, latency, consistency)
• [ ] Defined what is out of scope
• [ ] Confirmed target user base and geography

Estimation

• [ ] Calculated daily requests from DAU × requests per user
• [ ] Converted to average QPS (divide by ~100K)
• [ ] Applied peak multiplier (2–5x)
• [ ] Estimated storage (records × size × retention)
• [ ] Estimated bandwidth (QPS × response size)

Architecture

• [ ] Drew clients, load balancer, app servers, database
• [ ] Identified stateless vs stateful components
• [ ] Added caching for read-heavy paths
• [ ] Added CDN for static/media content
• [ ] Sketched key API endpoints (4–6)
• [ ] Sketched core database tables

Deep dive

• [ ] Identified the primary bottleneck at scale
• [ ] Presented at least one trade-off with pros and cons
• [ ] Discussed a failure scenario and mitigation
• [ ] Mentioned what changes at 10x scale

Communication

• [ ] Thought out loud throughout — interviewer should follow your reasoning
• [ ] Checked in with interviewer: "Does this direction make sense?"
• [ ] Summarized the design in 30 seconds at the end
• [ ] Did not over-engineer — matched complexity to stated scale

Phrases that score points

Use these naturally. Do not force them.

Phrases that lose points

Mock interview drill: practice this weekly

Pick one prompt. Set a 45-minute timer. Record yourself (voice memo is fine). Run the 4-step framework. Grade yourself against the checklist.

Beginner prompts:

• Design a URL shortener (like bit.ly)
• Design a paste bin (like Pastebin)
• Design a rate limiter

Intermediate prompts:

• Design a food delivery app (like Swiggy)
• Design a ride-sharing app (like Ola)
• Design a ticket booking system (like BookMyShow)

Advanced prompts:

• Design a real-time chat app (like WhatsApp)
• Design a video streaming platform (like Hotstar for IPL)
• Design a payment system (like UPI)
• Design a social media feed (like Twitter/X)

Do one mock per week for eight weeks. By week four, the 4-step framework will feel automatic. By week eight, you will be calmer than candidates who have read ten books but never timed themselves.

How this course fits together

You now have the full foundation for system design interviews and real architecture work:

1. Scaling Basics — server limits, vertical vs horizontal, load balancing
2. Data Layer Scaling — replicas, sharding, caching, CDN
3. Back-of-Envelope Estimation — start with URL shortener napkin math
4. This chapter — the 4-step framework; URL shortener walkthrough above
5. URL Shortener — full design depth in Lessons 7–8

Pair this course with the hands-on labs — Scaling, Request Flow, Sharding, and Consistency — to move from "I understand the theory" to "I have built it."

The candidates who get offers are not the ones who know the most technologies. They are the ones who ask the right questions, estimate honestly, design incrementally, and communicate their trade-offs clearly. That is what this framework trains.