How to Approach a System Design Interview

§1The Core Insight

A system design interview is not a test of whether you can invent Twitter. It is a test of five things:

At SDE-1/2 level, interviewers are checking for structured thinking + fundamentals. They are NOT expecting a globally-replicated multi-region design from scratch. A candidate who builds a clean single-region design and articulates why each piece exists beats a candidate who name-drops "Cassandra, CRDTs, cell-based architecture" without justification.

§2The 6-Phase Framework 45-min round

§3Phase 1: Requirements Clarification

Split into functional and non-functional. Say those exact words — it signals structure immediately.

Functional requirements (what the system does)

Ask 3–5 questions max. Good patterns:

• "Who are the users and what are the top 2–3 actions they take?"
• "Do we need X?" (for a URL shortener: custom aliases? expiry? analytics?)
• "Is this read-heavy or write-heavy?" — always ask this; it drives everything downstream
• "What's explicitly OUT of scope?" — then write the out-of-scope list down. Interviewers love this.

Non-functional requirements (how well it does it)

Cover these five. You don't need all of them every time, but touch each:

§4Phase 2: Back-of-Envelope Estimation

The goal is NOT precision. It is showing you can reason in powers of ten and let the numbers drive design decisions ("100 QPS → one Postgres box is fine; 100K QPS → we need to talk about sharding and caching").

Numbers to memorize — the only tables you need

Worked example 1 — your own platform as calibration

Worked example 2 — URL shortener (the classic)

Assume: 100M new URLs/month, 10:1 read:write

Writes:  10^8 / month ≈ 10^8 / (2.5×10^6 s) ≈ 40 writes/s
Reads:   400 reads/s average, ~1,200/s peak (3x)

Storage: 100M/month × 500 B/record (short code, long URL, metadata)
        = 5×10^10 B/month = 50 GB/month = 600 GB/year, ~3 TB over 5 yrs
        ⇒ fits on one big DB with replicas; sharding optional, not urgent

Bandwidth: 1,200 QPS × 500 B ≈ 600 KB/s — trivial.

Worked example 3 — event pipeline

Assume: 5,000 concurrent users, each generating 2 events/s
⇒ 10,000 events/s into the pipeline
Each event ~1 KB ⇒ 10 MB/s ingest — comfortable for one Kafka
cluster, but 10K individual OpenSearch writes/s would strangle it
⇒ batch (e.g. bulk index every 1s or every 5K docs).

This is literally your production architecture — you built batched OpenSearch ingestion for exactly this reason. Say so.

§5Phase 3: API Design

Keep it tight: 3–6 endpoints, REST unless there's a reason (streaming → SSE/WebSocket; internal service-to-service → gRPC is a fine mention). For each endpoint state: method, path, request, response, and auth.

POST /api/v1/urls
  body: { "long_url": "...", "custom_alias": "?", "expires_at": "?" }
  resp: 201 { "short_url": "https://sho.rt/Ab3xK9" }
  auth: API key / JWT

GET /{code}  → 302 Location: <long_url>   (301 vs 302: discuss caching!)

Things that mark you as someone who runs real APIs (sprinkle 2–3 in):

• Idempotency keys on any write that money or side effects depend on ("we do this for billing events — client sends Idempotency-Key, we dedupe server-side").
• Pagination on list endpoints (cursor-based > offset for large sets).
• Rate limiting headers (429, Retry-After, X-RateLimit-Remaining) — you built per-tenant rate limiting on Kong; this is home turf.
• Versioning (/v1/) and auth model (API key per tenant vs user JWT).

§6Phase 4: High-Level Design

Draw the boring, correct v1 first. Almost every system starts as:

                +-----------+
   clients ---> |    LB     | ---> [ API service  ] x N (stateless)
                +-----------+          |       |
                                       |       +-----> [ Cache (Redis) ]
                                       v
                                 [ Database ]  (primary + replicas)
                                       |
                                       +-----> [ Queue (Kafka) ] --> [ Workers ]
                                                                        |
                                                                        v
                                                                 [ Search / Analytics ]

Narrate left to right: entry point → compute → data → async. For every box, say why it exists in one sentence. "Stateless API tier so we can scale horizontally and any pod can serve any request — this is how our services run on Kubernetes behind Kong."

§7Phase 5: Deep Dives

Pick 1–2 components and go three levels down. A deep dive means covering, for that component:

• Data model / schema — actual columns/keys, indexes
• The hard problem — hot keys, ordering, exactly-once, thundering herd, cache invalidation
• Failure mode — what happens when this box dies; how we detect and recover
• The scaling story — what changes at 10x

Your strongest deep-dive territories (rehearse these — details in files 02, 03, 05, 06):

§8Phase 6: Wrap-Up — Tradeoffs and Failure Talk

Close with 2–3 of these, unprompted:

• "Single points of failure: the LB and the DB primary — here's how each fails over."
• "What I'd cut for v1 vs what I'd add at 10x scale."
• "The main tradeoff I made: I chose eventual consistency on reads to get X — if the product needed strong consistency, I'd change Y."
• "How I'd know it's healthy: the 2–3 metrics I'd put on a dashboard" (p99 latency, error rate, queue lag — you live in these).

§9The First 5 Minutes — A Script

Memorize the skeleton, improvise the content.

Why this works: in 90 seconds you've (a) shown a plan for the whole interview, (b) taken control of scope, (c) asked the read/write question that drives everything, and (d) created a checkpoint the interviewer can correct. Nothing you say later can be "wrong scope" — you negotiated it.

§10SDE-1/2 Expectations vs Senior — Calibrate Your Ambition

What separates a strong SDE-2 answer from a senior answer (so you know where the ceiling is): seniors are expected to drive ambiguity resolution themselves, weigh org-level concerns (team boundaries, migration paths, cost), and proactively design for failure domains. You get significant credit for merely gesturing at these: "at bigger scale I'd consider splitting this into its own service — similar to how our platform runs 20+ microservices with the gateway as the seam."

§11Probe Questions & Self-Test