System Design Interview Guide (2026)
System design interviews are the hardest to fake and the easiest to over-prepare for. The pattern is stable — requirements, capacity, API, data model, high-level architecture, deep dives on 2-3 components, discussion of tradeoffs. This guide covers the framework, the 8 canonical designs, and the specific follow-ups Google, Meta, and Amazon ask after your first answer works.
Beginner questions
1. Walk me through your system design framework. Beginner
Six-step framework. (1) Clarify functional + non-functional requirements — write 3-5 of each on the whiteboard. (2) Capacity — QPS, storage/day, bandwidth. (3) API — 3-5 endpoints with request/response. (4) Data model — tables + partitioning key + hot path. (5) High-level architecture — draw the boxes. (6) Deep dive — pick 2-3 components the interviewer signals interest in and go 3 layers deep. Never skip step (1). The whole interview is about how you clarify what you weren't told.
2. Design a URL shortener (like bit.ly). Beginner
Capacity: 100M shortens/day, 10:1 read:write = 12K QPS reads. Storage: 100M × 500B = 50GB/day. API: POST /shorten, GET /:code. Data model: (short_code CHAR(7) PK, long_url, created_at, expires_at). Short-code gen: base62(monotonic_id) — no collision handling needed. Cache the hot 20% in Redis (LRU). Read path: Redis → DB. Write path: DB → invalidate. Discuss custom aliases (unique constraint), analytics (separate clicks table, aggregate async).
Practice these live, in your voice
MiPrep's practice mode turns your resume into a rehearsed answer set. Talk through the idioms the way top-tier interviewers score.
Download MiPrep 🔒 Interview audio is never stored on our serversIntermediate questions
3. Design a rate limiter. Intermediate
Token bucket for burst tolerance, sliding window for strict enforcement. Distributed = Redis with atomic INCR + EXPIRE. Discuss: where does the counter live (per-key = per-user-per-endpoint), what happens on Redis failure (fail open? closed? — depends on business), how to handle clock skew across nodes (use Redis server time). Discuss the classic bug: race between INCR and EXPIRE — use Lua script for atomicity.
4. Design Twitter timeline. Intermediate
Two models. Fanout on write (push) — every tweet inserts into follower timelines. Fast reads, expensive writes for celebrity accounts (fan out to 100M followers). Fanout on read (pull) — read timeline queries per-followee. Slow reads, cheap writes. Twitter uses hybrid: push for regular users, pull for celebrity accounts, merge at read time. Storage: timeline as Redis sorted set (score = timestamp). Discuss eventual consistency, cache warming, cold start (new user follows 100 people).
5. Design a chat application (WhatsApp / iMessage). Intermediate
WebSocket long-lived connection per user, connection registry sharded by user_id. Send message: client → nearest edge → registry lookup → deliver to recipient's connection. Offline: enqueue to durable store (Cassandra by conversation_id), push notification. Read receipts: separate event stream, batched. Group chat: fan out at send (small groups) or read (large groups). Encryption: E2E means server never sees plaintext — use Signal Protocol (double ratchet + X3DH).
6. What are the SLOs / SLAs you'd set for a new API? Intermediate
Three-level model. SLI (indicator) — what you measure, e.g. p99 latency, 5xx rate, error budget burn. SLO (objective) — internal target, e.g. p99 < 200ms 99.9% of time. SLA (agreement) — customer contract, usually looser than SLO by 10x margin. Discuss error budget: if SLO is 99.9%, you have 43 minutes of allowed downtime per month. When you burn 50% in 12 hours, freeze deploys.
Advanced questions
7. Design a distributed file storage (Dropbox / Google Drive). Advanced
Client chunks file into 4MB blocks, hashes each, uploads only unseen hashes (dedup). Metadata service tracks file → chunk list, versions, permissions (SQL — Spanner or Postgres). Chunk storage in S3-equivalent. Sync via long-poll or WebSocket notifying client of metadata changes. Client rebuilds file from chunk list. Discuss conflict resolution (last-write-wins vs vector clock), delta sync (rsync-style), storage lifecycle (hot → cold).
8. Design YouTube (video streaming). Advanced
Upload path: client → chunked upload → object storage → transcoding queue → adaptive-bitrate variants (240p to 4K). Playback: client requests manifest (HLS/DASH) → CDN serves .ts segments. CDN sits in front of everything — 99% of bytes never touch origin. Metadata (title, views, likes) in SQL. View count is write-heavy: buffer in Redis, flush to DB every 5s, denormalize into video row. Recommendations: separate ML pipeline reading watch events from Kafka.
9. Design a payment system (Stripe). Advanced
Idempotency is the whole game. Every write endpoint takes Idempotency-Key header, hashed to a row in an idempotency table with (key, first_seen, response_body). Second request with same key returns cached response. Money movement uses double-entry ledger — every debit has a paired credit, ledger is append-only. Discuss: 2PC vs saga for multi-step (subscribe → charge → provision), reconciliation (nightly compare bank statement vs ledger), refund idempotency, PCI scope (keep card data out of primary DB, use vault).
Common mistakes candidates make
- Jumping straight to the whiteboard without capacity math — every senior interviewer waits 60 seconds to see if you'll do it, and marks down if you don't.
- Designing for infinite scale when the problem says 1000 QPS — 'scale it later' is a valid answer and shows judgment.
- Adding Kafka for a single-writer use case — always ask 'why not just a queue' before naming Kafka.
- Forgetting the failure modes: what if the primary DB goes down mid-write, what if the cache is cold, what if a network partition splits the cluster.
- Using microservices in the answer when the interviewer asked for the system design of one product feature — over-decomposition is a red flag.
Study strategy
Two-week plan. Week 1: read Alex Xu Vol I chapters 1-6, take notes on each canonical design (URL shortener, chat, Twitter timeline, YouTube, distributed cache, distributed queue). Do capacity math from scratch — do not memorize numbers, derive them. Week 2: 3 mock interviews per week with a real engineer (exponent.com or friends). Time-box each answer to 45 minutes. After each mock, write down the ONE follow-up question you couldn't answer and study that specifically.
Do timed mocks with MiPrep before the real thing
Upload your resume and target job description. MiPrep generates a rehearsed answer set in your voice from your own projects — so mock interviews sound like real ones.
Get MiPrep — free 🔒 Interview audio is never stored on our servers