System design interviews

How the system-design round works and how to run it: expectations by level, a minute-by-minute framework, estimation drills, how to drive the conversation, and nine worked designs in the same compact 7-step shape. The concepts behind every decision (caching, replication, quorums, queues, Bloom filters…) are in System design concepts; numbers and production tables are in System design, which also has the worked URL shortener. Coding rounds: Coding interviews.

Format & expectations

A 45–60 minute conversation around a vague prompt ("design Instagram"). There is no single right answer: you're scored on how you scope, decide, justify and adapt. Usually on a virtual whiteboard (Excalidraw, Miro, a shared doc) or a real one.

Variants: product design (design Twitter), infrastructure design (design a rate limiter, a KV store), ML system design (design a recommendation pipeline), and architecture deep dive into a system you built. The framework below works for all of them.

The framework

Sums to 45 and 60. Watch the clock: if the high-level design isn't on the board by minute 20, cut estimation and API detail. The same framework with output checklists: System design: Approach framework.

Estimation drills

Latency numbers, powers of two and the full formulas: System design: Back-of-envelope numbers.

Worked estimate: a Twitter-like feed

Worked estimate: a chat app

How to drive

Clarifying questions

Behaviors that score

Drawing tips

• Left to right: clients → edge (CDN, LB, gateway) → services → data stores; async parts (queues, workers) below.
• Number the arrows of the write path and the read path separately, or draw them in two colors.
• Label arrows with what flows (post_id, event), stores with their key (messages (conv_id, seq)).
• Keep a corner for requirements and numbers; point back at them when you decide something.
• Redraw rather than squeeze: a clean second diagram beats a tangle.

Design: rate limiter

Requirements. Functional: limit requests per client (user, API key or IP) per rule (100/min on POST /login); return 429 with Retry-After; rules change without deploys. Non-functional: adds under 5 ms, available (the API must work if the limiter doesn't), approximately accurate across many API servers. Out of scope: network-level DDoS (CDN/WAF), billing quotas.

Estimates. 1M requests/s across the fleet, 10M active keys × ~64 B of state ≈ 640 MB: fits one Redis, but 1M operations/s needs a sharded cluster (~10 shards at an assumed 100k ops/s each).

API. Internal call from the gateway middleware; clients only see headers.

allow(key="user:42", rule="login") →
  { allowed: false, remaining: 0, retryAfterMs: 1200 }
 
HTTP/1.1 429 Too Many Requests
Retry-After: 2

Data model. Redis hash per key and rule, rl:login:user:42 → { tokens, ts }, with a TTL equal to the time to refill. Rules in a config store, cached in every gateway.

High-level design.

client ─► API gateway / middleware ──allowed──► service
             │  ▲
   Lua script│  │ allowed, remaining, retry-after
             ▼  │
       Redis cluster (sharded by limiter key)
 
rules service ─► pushes rule config to every gateway

Deep dives.

Trade-offs. Exact global counting costs a network hop per request; local approximate limits are free but overshoot. Failing open keeps the product up during limiter outages at the price of brief unlimited traffic.

Design: news feed

Requirements. Functional: post (text and media), follow, home feed in reverse-chronological order, paginated. Non-functional: feed loads under 500 ms p99; a post shows up in followers' feeds within seconds (eventual consistency is fine); very read-heavy; highly available. Out of scope: ads, ML ranking internals, DMs.

Estimates. From the worked estimate: 20k feed QPS (60k peak), 1k posts/s, 200k feed inserts/s if every post fans out.

API.

POST /v1/posts          { text, mediaIds[] } → { postId }
GET  /v1/feed?cursor=<lastPostId>&limit=20
POST /v1/users/{id}/follow

Data model. posts (post_id Snowflake, author_id, text, media, created_at) sharded by author_id; follows stored twice, keyed by follower and by followee; feed cache: a Redis list per user feed:{user_id} of the latest ~800 post IDs.

High-level design.

            ┌─► post service ─► posts DB (by author_id)
            │        │
client ─► LB┤        ▼ post.created
            │      Kafka ─► fan-out workers ─► feed cache
            │                  │ followers     (Redis list
            │                  ▼ from graph     per user)
            │              social graph DB
            └─► feed service ─► feed cache + celebrity posts
                     │           merge, hydrate IDs
                     ▼
              post cache, user cache;  media via CDN

Deep dives.

Trade-offs. Push makes reads one lookup but multiplies writes and storage; pull is cheap to write but slow to read for people who follow many accounts. The hybrid adds a merge step and a threshold to tune.

Design: chat

Requirements. Functional: 1:1 and group chat (up to ~1,000 members), delivery receipts (sent, delivered, read), presence, offline delivery with push notifications, history synced across devices. Non-functional: delivery in a few hundred ms, no message lost, correct order within a conversation, highly available. Out of scope: voice and video; end-to-end encryption (mention: servers store ciphertext).

Estimates. From the worked estimate: 20k messages/s (60k peak), 7.5M open WebSockets, ~146 TB/year before replication.

API. WebSocket frames for live traffic, REST for history.

→ send  { convId, clientMsgId, body }
← ack   { clientMsgId, msgId, seq }        stored durably
← msg   { convId, seq, msgId, sender, body }
→ read  { convId, upToSeq }
GET /v1/conversations/{id}/messages?beforeSeq=900&limit=50

Data model. messages (conv_id, seq, msg_id, sender_id, body, created_at) in a wide-column store (Cassandra/ScyllaDB): partition by conv_id, cluster by seq. members (conv_id, user_id, last_read_seq). Session registry in Redis: user_id → gateway server.

High-level design.

client ◄══ WebSocket ══► chat gateway (stateful, holds sockets)
                            │ send          ▲ deliver
                            ▼               │
                      chat service ─► per-conversation seq
                            │         (Redis INCR / partition)
             ┌──────────────┼───────────────┐
             ▼              ▼               ▼
       messages DB   session registry   push service
      (conv_id, seq)  user → gateway    APNs / FCM for
                        (Redis)          offline users

Deep dives.

Trade-offs. WebSockets give instant two-way delivery but make gateways stateful (draining, sticky routing, a registry). A per-conversation sequencer guarantees order but is a hot spot for very busy conversations.

Design: notification system

Requirements. Functional: internal services send notifications through push (iOS, Android), SMS, email and in-app; templates with localization; user preferences and opt-outs; scheduling and quiet hours; delivery and open tracking. Non-functional: transactional messages (2FA codes) in seconds, bulk campaigns can take minutes; no loss; duplicates rare; absorbs spikes. Out of scope: the campaign authoring tool.

Estimates. 10M push + 5M email + 1M SMS a day ≈ 200/s average; a campaign of 10M in 10 minutes ≈ 17k/s: queues absorb the spike, workers drain at provider limits.

API.

POST /v1/notifications
Idempotency-Key: order-981-shipped
{ "userId": "u1", "template": "order_shipped",
  "params": { "orderId": "981" },
  "channels": ["push", "email"],
  "priority": "transactional" }
 
202 Accepted  { "notificationId": "n_7f3" }

Data model. notifications (id, user_id, template, params, created_at), deliveries (notification_id, channel, status, attempts, provider_id), preferences (user_id, category, channel, opted_in, quiet_hours), devices (user_id, token, platform, last_seen), versioned templates.

High-level design.

services ─► notification API ─► dedupe (idempotency key)
                  │
                  ▼
     preferences + per-user limits ─► render template
                  │
       ┌──────────┼──────────┬──────────┐
       ▼          ▼          ▼          ▼
  push queue   SMS queue  email queue  in-app queue
  (per priority: transactional ≠ bulk)
       │          │          │          │
       ▼          ▼          ▼          ▼
  APNs / FCM   SMS vendor  email vendor  inbox + WebSocket
       └──── status callbacks ─► deliveries DB, retries, DLQ

Deep dives.

Trade-offs. Checking preferences at send time (not enqueue time) respects late opt-outs but adds a lookup per message. More channels and vendors improve reach and resilience at the cost of more integration code.

Design: typeahead

Requirements. Functional: top 5–10 completions for the typed prefix, ranked by popularity; refresh at least daily, with trending terms sooner. Non-functional: results visible under ~100 ms while typing (server budget ~10–20 ms); very high read QPS; slight staleness fine. Out of scope: spell correction, the search results page.

Estimates. 100M DAU × 10 searches × ~6 requests per search (debounced) = 6B/day ≈ 60k QPS, ~150k at peak. 10M popular queries; the prefix → top-k map is a few GB to tens of GB: fits in RAM, so replicate rather than shard.

API.

GET /v1/suggest?q=new%20yo&limit=8
200 ["new york times", "new york weather", …]
Cache-Control: public, max-age=300

Data model. Offline: query_counts (query, day, count) built from search logs. Serving: a trie where each node stores its top-k completions, or a flat map prefix → [top-k queries].

High-level design.

client: debounce ~100 ms, cancel stale requests,
        cache results per prefix
   │
   ▼
CDN / edge cache (popular prefixes, TTL minutes)
   │ miss
   ▼
suggest service ─► in-memory prefix → top-k (replicas)
                        ▲ load new snapshot, swap atomically
search logs ─► Kafka ─► aggregation job (counts, time decay)
                        ─► build job ─► snapshot in object store

Deep dives.

Trade-offs. Precomputing top-k makes reads trivial but rebuilds cost compute and add staleness; a streaming layer buys freshness with complexity. Replication over sharding wastes RAM but avoids fan-out per keystroke.

Design: web crawler

Requirements. Functional: from seed URLs, fetch HTML pages, extract links, store pages for an indexer, recrawl pages as they change. Non-functional: 1B pages a month; polite (obey robots.txt, limit requests per host); robust to traps and broken HTML; no duplicate work. Out of scope: indexing and ranking, JavaScript rendering (a headless-browser pool is an extension).

Estimates. 1B / 2.6M s ≈ 400 pages/s, ~1,000 at peak. At 100 KB per page: 40 MB/s inbound and 100 TB a month before compression.

API. Internal: seed(urls); output is pages in the content store plus a page.fetched event for the indexer.

Data model. URL frontier (priority queues feeding per-host queues); seen-URL set (Bloom filter in front of a store keyed by URL hash); pages (url_hash, url, fetched_at, status, content_hash, next_crawl_at); page bodies in object storage by content hash.

High-level design.

seeds ─► URL frontier ───────────────► fetcher workers
          front: priority queues        │   ▲ DNS cache
          back: one queue per host      │   │ robots.txt cache
             ▲                          ▼
             │                    content store (S3)
             │                    + pages metadata DB
             │                          │
   seen? (Bloom + store)                ▼
   normalize, filter ◄── link extractor ◄── parser, dedupe
                                         (content hash, SimHash)

Deep dives.

Trade-offs. Politeness caps throughput per host, so parallelism must come from many hosts at once. A Bloom filter saves memory but occasionally skips a new URL; a full seen-set is exact but costs a lookup per link.

Design: proximity search

Requirements. Functional: find businesses near a point within a radius, filter by category, sort by distance or rating; owners add and edit businesses; view details. Non-functional: search under 200 ms p99; very read-heavy; edits can take minutes to appear; highly available. Out of scope: reviews, map rendering, directions.

Estimates. 200M businesses × 1 KB = 200 GB of details. Geo index entries (ID + geohash + lat/lng ≈ 32 B) × 200M ≈ 6.4 GB: fits in memory. 100M DAU × 5 searches = 500M/day ≈ 5k QPS, ~15k peak.

API.

GET /v1/search?lat=40.73&lng=-73.99&radius=2000
    &category=coffee&cursor=…&limit=20
GET /v1/businesses/{id}
POST /v1/businesses     (owners, rate limited)

Data model. businesses (id, name, lat, lng, category, rating, …) in Postgres as the source of truth. Geo index: (geohash, business_id) with a B-tree on geohash, or PostGIS with a GiST index, or an in-memory quadtree service.

High-level design.

client ─► LB ─► search service ─► geo index service
                     │             (in memory, replicated;
                     │              geohash or quadtree)
                     │             → candidate IDs
                     ▼
             business cache (Redis) ─► businesses DB
                                           │ CDC / events
owners ─► business service ─► DB ──────────┴─► index updater

Deep dives.

Trade-offs. Geohash is easy to store and shard but has cell-edge effects (hence neighbors); quadtrees fit density better but live in memory and need rebuilding. Minutes of index lag keep writes cheap.

Design: video streaming

Requirements. Functional: upload videos, transcode into several resolutions, stream with adaptive bitrate on any device, video metadata. Non-functional: playback starts in about 2 s with rare rebuffering; global viewers; uploads never lost; egress cost under control. Out of scope: recommendations, comments, DRM details, live streaming (differences noted below).

Estimates. 500k uploads/day × 5 min; ~500 MB per video across all renditions → 250 TB/day of new storage. Viewing: 100M views/day × 5 min × 5 Mbps ≈ 1.5 × 10^11 Mb/day ≈ 1.7 Tbps average egress: only a CDN can serve that.

API.

POST /v1/videos          → { videoId, uploadUrls[] }
PUT  <presigned part URL>        (multipart, resumable)
POST /v1/videos/{id}/complete
GET  /v1/videos/{id}     → { title, status, manifestUrl }
GET  cdn/v/{id}/master.m3u8      (HLS manifest)

Data model. videos (id, owner_id, title, status: uploading → processing → ready, duration), renditions (video_id, height, bitrate, codec, playlist_path). Object storage: raw/{id} and hls/{id}/{rendition}/seg_00001.m4s.

High-level design.

creator ─► upload API ─► multipart PUTs ─► object store (raw)
                                              │ upload event
                                              ▼
                     transcode DAG: split into chunks →
                     encode renditions in parallel →
                     package HLS/DASH, thumbnails
                                              │
                                              ▼
viewer ◄── CDN / ISP caches ◄──── object store (segments)
   │ manifest, then segments
   └─► video API ─► metadata DB (status, renditions)

Deep dives.

Trade-offs. More renditions mean smoother playback on bad networks but more storage and encode time. Pre-positioning at the edge cuts egress and latency for hits but wastes cache on videos nobody watches.

Design: key-value store

A Dynamo-style store, as in the Dynamo paper (opens in a new tab) and Cassandra.

Requirements. Functional: get(key), put(key, value), delete(key); values up to ~1 MB. Non-functional: always writable, tunable consistency, horizontal scale to hundreds of nodes, single-digit ms p99 in a region, durable. Out of scope: transactions, secondary indexes, range scans.

Estimates. 10 TB × 3 replicas = 30 TB; at ~2 TB usable per node → ~15 nodes for space; 1M ops/s at an assumed 50k ops/s per node → ~20 nodes. Plan ~25–30 for headroom.

API.

get(key, consistency=QUORUM) → [(value, version)]
    more than one version = siblings to merge
put(key, value, context, consistency=QUORUM)
    context = the version from the previous get
delete(key) → writes a tombstone

Data model. Each node runs an LSM engine: commit log → memtable → SSTables with Bloom filters, compacted in the background. Cluster state: ring membership and token ownership, spread by gossip.

High-level design.

client ─► any node = coordinator for this request
             │ hash(key) on ring → preference list: next N=3
    ┌────────┼────────┐       distinct physical nodes
    ▼        ▼        ▼
  node B   node C   node D    write: wait for W=2 acks
  (LSM)    (LSM)    (LSM)     read: ask R=2, newest wins,
    ▲        ▲        ▲       repair stale replicas
    └── gossip membership, Merkle-tree anti-entropy
  D down → node E keeps D's writes as hints (hinted handoff)

Deep dives.

Trade-offs. Choosing availability (AP) means clients see conflicts or stale reads; a consensus-based CP store (etcd, Spanner) avoids that but rejects writes without a majority. LWW is simple but loses data under concurrency; version vectors keep it but push merging to clients.

Common mistakes

Scoring rubric

Interviewers write down specific evidence for each dimension. Make evidence easy to write: say the requirement, the options, the decision and the cost, in that order.

Prep plan

Resources: System Design Primer (opens in a new tab), Designing Data-Intensive Applications (opens in a new tab), Alex Xu's System Design Interview vol. 1 and 2, Hello Interview (opens in a new tab), ByteByteGo (opens in a new tab). With a week or less: the framework, the estimation table, and three designs practiced out loud.

Recipes

The first 5 minutes

A script that turns a one-line prompt into a scoped problem.

1. "Let me make sure I understand what we're building. The core features are A, B and C; is that right? Anything you want to add or drop?"
2. "Who uses it and how much? Roughly how many daily users, and is it global?"
3. "What matters most: latency, availability, consistency? Can a user see stale data for a few seconds?"
4. "I'll leave out D and E unless you want them."
5. Write the list in a corner: features, numbers, non-functional targets, out of scope. "I'll do a quick estimate next."

Estimation template

Fill in, round hard, circle the numbers that change the design.

DAU                    = ______
actions/user/day       = ______   (reads ____, writes ____)
avg QPS  = DAU × actions / 10^5  = ______   peak ×3 = ______
read:write ratio       = ______
bytes per write        = ______
storage/year = writes/day × bytes × 400 × 3 replicas = ______
bandwidth    = peak QPS × bytes per response        = ______
cache        = 20% of daily hot data                = ______
servers      = peak QPS / (QPS per server)          = ______
→ implications: ______________________________________

Deep-dive question bank

Questions to ask yourself about each box before the interviewer does.

Wrap-up in 3 minutes

• One-sentence recap of the design and the two key decisions.
• The main bottleneck at 10x and how you'd address it.
• The biggest risk or weakest point you know about.
• What you'd build next (monitoring, multi-region, a feature you left out).

When you're stuck

• Re-read the requirements and numbers; the answer is usually a constraint you forgot.
• Solve it for one server, then ask "what breaks first when this gets 100x the load?"
• Name two options and compare them on the requirement that matters most.
• Ask a targeted question: "Is it acceptable if a user sees their own post a second late?"

Practice loop for one design

1. Set a 45-minute timer; talk out loud; draw on a real whiteboard tool.
2. Afterward, compare with a reference design (Primer, Alex Xu, Hello Interview) and note what you missed.
3. Score yourself on the rubric; write the 3 gaps.
4. Redo the same design three days later in 30 minutes.

References

• Amazon Dynamo paper (opens in a new tab): the model for the key-value store design
• Mercator: a scalable, extensible web crawler (opens in a new tab): URL frontier with priority and politeness queues
• RFC 9309: Robots Exclusion Protocol (opens in a new tab) and RFC 8216: HLS (opens in a new tab): crawler and streaming standards
• Twitter: Timelines at Scale (opens in a new tab): hybrid fan-out in production
• Discord: how Discord stores trillions of messages (opens in a new tab): chat storage on Cassandra and ScyllaDB
• The System Design Primer (opens in a new tab): free topic index and practice designs
• Designing Data-Intensive Applications (opens in a new tab): the concepts in depth
• Alex Xu, System Design Interview vol. 1 and 2 (ByteByteGo (opens in a new tab)): worked designs in interview format
• Hello Interview: system design in a hurry (opens in a new tab): delivery framework and level expectations
• System design concepts: the building blocks behind every decision here
• System design (production reference): numbers, tables and the worked URL shortener