What you'll learn

By the end of this you'll have a repeatable structure for any system design prompt — what to ask first, how to estimate scale, how to draw a simple working system before adding Redis and Kafka, and how to deep-dive one component without rambling for forty minutes.

System design is the interview type most engineers dread and most companies weight heavily past mid-level. This guide is the on-ramp, not the encyclopedia.

Who this is for

  • Mid-level engineers facing system design for the first time
  • Developers who've done rounds but felt they were improvising
  • Backend or full-stack candidates targeting senior roles

You can skip this if you're early-career and the loop explicitly excludes design — many junior screens focus on coding and fundamentals only.

What system design interviews are

Plain English: you and the interviewer co-design a system on a whiteboard (or shared doc) in 35–45 minutes. There is no single correct architecture. They watch how you clarify messy problems, make tradeoffs, and communicate.

You're not delivering a production spec. You're showing you won't deploy a monolith to Mars without asking how many users live there.

Prerequisites

  • Basic web architecture: browser, HTTP, app server, database
  • Familiarity with caches, queues, and load balancers at a headline level
  • Ability to do rough multiplication (users × actions × bytes)

Reading one or two postmortems or architecture blog posts helps more than memorizing fifty service names.

Setup from zero

Step 1 — Learn one framework by rote

Requirements → estimates → high-level diagram → bottlenecks → deep dive → revisit requirements. Say it until automatic. The framework frees brain space for thinking.

Step 2 — Practice three classic prompts

URL shortener, rate limiter, news feed — not because they'll definitely ask, but because patterns reuse everywhere (key-value, counters, fan-out reads).

Step 3 — Do one mock with a timer

45 minutes, voice recorded. Notice if you draw microservices in minute three. Stop that.

Little tip: when the interviewer gives vague scale ("millions of users"), assume a number out loud and keep moving. "I'll assume 5M DAU and 100:1 read/write — tell me if that's off." Decisiveness scores.

The mental model

Every design choice trades consistency, availability, latency, cost, and complexity.

CAP theorem is the academic version; interviews want plain language: "Can a stale cache show old avatar for 30 seconds? Probably yes. Wrong bank balance for 30 seconds? No."

When stuck, ask: what breaks first at 10× traffic? Follow the bottleneck — DB writes, hot keys, single leader, fan-out — and propose the smallest fix that addresses it.

Key terms

Horizontal scaling — more machines, not bigger ones.

Sharding — partition data by key across nodes.

CDN — edge caches for static or cacheable content near users.

Message queue — buffer between producer and consumer; absorbs spikes, enables retries.

Read replica — copy of DB for reads; replication lag means eventual consistency.

Load balancer — distributes traffic; needs health checks and redundancy itself.

Idempotency — repeating the same write doesn't double-charge or duplicate records; critical for retries and queues.

Fan-out — one write triggers many downstream updates (feeds, notifications); often async via queue.

Step-by-step

Phase A — Clarify (3–5 min)

Ask: scale (DAU, QPS), read vs write ratio, latency targets, consistency needs, geographic scope, mobile vs web, MVP vs full vision.

Example Q&A

Interviewer: "Design a URL shortener."

You: "Should we optimize for read-heavy redirect traffic or write-heavy creation? Do we need click analytics? Any custom alias URLs or only random short codes?"

---

Phase B — Estimate (3–5 min)

Round numbers. 10M links created/month ≈ 4 writes/sec average (peak higher). 100:1 reads → hundreds to low thousands of redirects/sec. Storage: billions of rows over years — plan sharding or ID generation accordingly.

---

Phase C — High-level design (5–8 min)

Client → CDN (static) → Load balancer → App servers → Cache (Redis)
                                              ↓
                                         Database (+ replicas)

Walk one write (create short URL) and one read (redirect). Name data stores.

---

Phase D — Bottlenecks & fixes

  • Single DB → read replicas, cache hot URLs
  • Hot key on viral link → cache with TTL, possibly pre-warm
  • ID generation → coordinated counter or base62-encoded IDs; avoid random collision loops at scale

---

Phase E — Deep dive (10–15 min)

Interviewer picks: "How do you generate short codes?"

You: "Base62 of monotonic ID from a small ID service or DB sequence — fixed length, no collision checks. Analytics via async queue so redirects stay fast."

Follow-up: "Cache miss storm?" — single-flight lock, pre-warm popular keys.

---

Q: Design a news feed (common variant)

Clarify: fan-out on write vs fan-out on read? Celebrity with 10M followers changes the answer.

Sketch: Users follow authors. On write, push post IDs to follower feed caches (write fan-out) for normal users; for celebrities, merge on read. Store posts in DB, feed as sorted list in Redis or precomputed tables. Pagination via cursor, not offset, at scale.

Tradeoff line: Write fan-out is fast reads, expensive writes for popular authors. Hybrid approaches are what real systems use.

---

Q: How do you choose SQL vs NoSQL?

Answer: Relational when you need joins, transactions, and invariant constraints (orders, inventory). Document/KV when access pattern is simple key lookup, schema varies, or horizontal shard is primary need. Say you'd default SQL until profile proves otherwise — interviewers like grounded defaults.

Working examples

Napkin math snippet (say out loud)

100M users × 2 posts/day = 200M posts/day
200M / 86,400 ≈ 2,300 writes/sec average
Peak ×3 ≈ 7k writes/sec → shard or queue writes

Rate limiter sketch (often a sub-question)

Token bucket in Redis: fixed refill rate, max burst, 429 with Retry-After. Per-user limits for auth API, per-IP for anonymous.

Session storage sketch

Sticky sessions → hard to scale; avoid if possible
External session store (Redis) → app servers stay stateless
JWT in cookie → stateless but harder to revoke instantly; mention refresh + blocklist if asked

Patterns and when to use them

| Building block | When |
|----------------|------|
| Cache | Read-heavy, tolerable staleness |
| Queue | Async work, spike smoothing, retries |
| Sharding | Write/storage ceiling on single DB |
| CDN | Static assets, cacheable API responses |
| Search index (Elasticsearch) | Full-text search, not primary source of truth |

Little tip: start monolith + Postgres + Redis until math forces distribution. Premature microservices is one of the fastest ways to lose a design interview.

Common mistakes

Drawing 12 boxes before requirements. Clarify first — always.

No numbers. "Lots of users" is not a design input.

Ignoring failures. What if cache is down? DB replica lag? Say it briefly.

Database as blob. Pick relational vs document vs KV with one sentence of why.

No observability. Metrics, logs, alerts — one minute shows ops maturity.

Over-indexing on buzzwords. Kafka, Cassandra, and Kubernetes each solve real problems — none belong on the diagram until math or failure modes require them.

Forgetting the user path. Always narrate one happy-path request after drawing boxes. Interviewers use this to see if the diagram is coherent.

Troubleshooting

Freeze on unknown domain: Map to known pattern — "feed" is fan-out reads; "shortener" is KV + redirect; "chat" is WebSockets + message store + presence optional.

Running out of time: Stop adding features; validate design against initial QPS and close loop. "Given 10k writes/sec, sharded write path handles it; at 100k we'd revisit ID generation."

Interviewer silent: They often want you to drive. State assumption, propose next step.

Pushed on CAP theorem: Don't recite proofs — give one example where you'd pick availability over strong consistency and one where you wouldn't.

Asked about multi-region: Mention replication lag, routing users to nearest region, and which data must stay strongly consistent globally vs can be regional.

Checklist

  • [ ] Open with clarifying questions, not boxes
  • [ ] Did napkin math out loud
  • [ ] Drew simple client → LB → app → DB first
  • [ ] Identified first bottleneck at scale
  • [ ] Deep-dived one component with tradeoffs
  • [ ] Closed by checking against requirements

Practice task

Set a 40-minute timer. Design "paste bin" — users paste text, get URL, optional expiry. Write requirements you'd ask, estimates, diagram, and one deep dive. Grade yourself: did you talk tradeoffs or only name technologies?

Then redo only the deep dive for a different component — say object storage for large pastes vs DB for small text — in five minutes. Flexibility on second passes is what separates practiced candidates.

FAQ

Do I need to know Kubernetes?
Helpful but not mandatory. Know containers and horizontal scaling conceptually.

Real-time vs eventual consistency?
Define per feature. Feeds tolerate lag; payments often don't.

Should I mention specific cloud services?
Generic names (managed DB, object storage) are fine unless they use AWS/GCP exclusively.

Staff-level difference?
More depth on failure domains, multi-region, org constraints — still same framework.

How much detail on databases?
Schema sketch, indexes for hot queries, when to shard — you don't need full DDL, but "users table keyed by id, feeds stored as sorted post ids" level of concreteness helps.

Whiteboard vs doc?
Same framework either way. Label arrows, speak while drawing, leave space to add cache or queue when bottlenecks appear.

What to learn next

  • Developers hub caching and rate-limiting tutorials for component depth
  • Node.js interview prep — many design sessions assume backend fluency
  • JavaScript deep cuts — lighter design rounds still need clear communication
  • [Node.js interview prep](/interview/nodejs-interview-prep)
  • [React interview questions](/interview/react-interview-questions)
  • [AI tools interview angles](/interview/ai-tools-interview-angles)

Takeaways

System design interviews reward structure and tradeoff language, not buzzword bingo. Clarify, estimate, draw the simple thing, find what breaks, go deep once, loop back.

Practice three classics, mock once on a timer, and get comfortable stating assumptions. Interviewers remember candidates who drive the conversation calmly.

If you remember only one thing: ask scale and read/write ratio before you draw a single box — every good design starts with constraints, not technologies.