2026-07-11 · System Atlas

Top 10 System Design Interview Questions

If you're preparing for a software engineering interview at a top tech company, you must master the system design round. While coding interviews test your algorithmic thinking, system design interviews test your ability to build scalable, reliable, and maintainable distributed systems.

Below are the ten most frequently asked questions. For each one: the core challenge, how to approach it in the room, the key concepts to name, and the follow-up the interviewer is most likely to hit you with. If you don't yet have a repeatable structure for these interviews, read How to Answer Any System Design Question first — every answer below assumes that clarify → estimate → design → deep-dive rhythm.

1. Design a URL Shortener (e.g., TinyURL)

This is the classic "Hello World" of system design interviews — asked constantly precisely because it looks simple and isn't.

  • Core challenge: Designing a highly available, read-heavy system that generates unique, short aliases for long URLs.
  • How to approach it: Establish the read:write ratio early (typically ~100:1) and say the conclusion out loud: this is a cache-first design. For key generation, compare base62-encoding a counter (simple, but the counter is a single point of failure) against pre-allocated key ranges per server (no coordination on the hot path). Redirects should be a cache hit; the database is only for misses.
  • Key concepts: Base62 encoding, hash collisions, database indexing, caching (Memcached/Redis), 301 vs 302 redirects (permanent redirects get cached by browsers — great for load, terrible for analytics).
  • Likely follow-up: "How do you delete or expire links if browsers cached the 301?" and "How would you add click analytics without slowing the redirect path?" (Answer: async events on a message queue.)
  • Deep dive: Read the URL Shortener case study

2. Design a Rate Limiter

A fantastic question that tests your understanding of edge architecture and API gateways — and one of the few questions small enough to design completely in 45 minutes, so precision matters.

  • Core challenge: Restricting the number of requests a user can make within a time window, across a distributed cluster of servers that don't share memory.
  • How to approach it: Start local (token bucket in one process), then distribute. The interesting part is the distributed state: a Redis counter with atomic operations is the standard answer; mention the race condition between read and increment and how Lua scripts or INCR-first patterns solve it.
  • Key concepts: Token bucket vs leaky bucket vs sliding window log/counter, Redis for shared state, race conditions, what to return (HTTP 429 + Retry-After), fail-open vs fail-closed when the limiter itself is down.
  • Likely follow-up: "Your Redis instance dies — do you let all traffic through or block everything?" There's no free lunch; name the trade-off explicitly.
  • Deep dive: Try the interactive rate limiter simulation — watch each algorithm handle the same burst differently.

3. Design a Key-Value Store

This question dives deep into database internals — it's effectively "re-derive DynamoDB from first principles."

  • Core challenge: Building a distributed hash table that scales horizontally, survives node failures, and lets the caller tune consistency.
  • How to approach it: Partition with consistent hashing (so adding a node doesn't reshuffle everything), replicate each key to N nodes, and expose quorum knobs (R + W > N gives you strong reads). Then handle the failure modes: hinted handoff for short outages, Merkle trees for anti-entropy repair, vector clocks (or last-writer-wins) for conflicting writes.
  • Key concepts: Consistent hashing, CAP theorem, quorum consensus, vector clocks, Merkle trees, LSM trees and Bloom filters for the storage engine.
  • Likely follow-up: "Two clients wrote different values to the same key during a partition — walk me through exactly what happens when it heals."

4. Design a Message Queue (e.g., Kafka)

A must-know for asynchronous processing, and increasingly common as a standalone question.

  • Core challenge: Accepting, storing, and delivering messages reliably at massive scale — without losing any, and ideally without delivering them twice.
  • How to approach it: Anchor on the log abstraction: an append-only, partitioned commit log with consumer offsets. Sequential disk I/O is why Kafka is fast — say that. Then work the delivery-guarantee ladder: at-most-once, at-least-once, exactly-once, and why "exactly-once" really means "at-least-once plus idempotent consumers."
  • Key concepts: Pub/sub vs point-to-point, consumer groups, partitioning and ordering guarantees (ordered within a partition only), write-ahead logs, dead-letter queues, backpressure.
  • Likely follow-up: "A consumer crashes after processing a message but before committing its offset — what happens?" (It reprocesses: this is why handlers must be idempotent.)
  • Deep dive: Try the message queue simulation, then see a production-style Kafka retry pipeline architecture.

5. Design a News Feed (e.g., Twitter/Facebook)

The quintessential social media architecture question, and the cleanest test of whether you can reason about read vs write amplification.

  • Core challenge: Serving a personalized feed of updates from a user's network with extremely low latency.
  • How to approach it: The entire question is fan-out-on-write (precompute feeds into per-user caches; fast reads, expensive writes) versus fan-out-on-read (compute at request time; cheap writes, slow reads). The strong answer is the hybrid: fan-out on write for normal users, fan-out on read for celebrities with millions of followers. If you only remember one thing, remember the celebrity problem.
  • Key concepts: Fan-out strategies, Redis caching, cursor-based pagination, feed ranking as a separate service, sharding the social graph.
  • Likely follow-up: "Lady Gaga posts — what exactly happens in your system in the next five seconds?"
  • Deep dive: Read the News Feed case study

6. Design a Chat System (e.g., WhatsApp)

Tests your understanding of real-time communication and stateful connections — a different muscle from the request/response systems above.

  • Core challenge: Maintaining millions of persistent connections and guaranteeing message delivery to devices that are frequently offline.
  • How to approach it: WebSockets for the persistent connection; a connection registry (which gateway holds user X's socket?) so chat servers can route messages; a message queue between accept and delivery so nothing is lost when the recipient is offline. Sequence numbers per conversation give you ordering and read receipts almost for free.
  • Key concepts: WebSockets vs long polling, connection gateways as stateful services (they can't sit behind a normal load balancer naively), delivery acknowledgments, push notifications for offline users, end-to-end encryption as a follow-up.
  • Likely follow-up: "How does group chat change your design?" (Fan-out moves server-side; ordering across members gets harder.)
  • Deep dive: Read the Chat System case study, then compare with the WhatsApp architecture example.

7. Design a Ride-Sharing App (e.g., Uber/Lyft)

A complex system involving real-time geolocation matching — usually reserved for senior loops, where the interviewer wants to see decomposition into services.

  • Core challenge: Matching riders with drivers efficiently while ingesting a firehose of fast-moving geospatial data.
  • How to approach it: Split the problem immediately: location ingestion (drivers ping every few seconds — write-heavy, ephemeral data that belongs in memory, not a durable database), matching (geospatial index + dispatch logic), and trip management (stateful, durable, transactional). The geospatial index is the star: geohashes or quadtrees to turn "drivers near me" into a cheap lookup.
  • Key concepts: Quadtrees vs geohashes, in-memory location stores, dispatch as a state machine, surge pricing as a separate read path, replication for the trip store.
  • Likely follow-up: "Two dispatchers match the same driver to two riders simultaneously — how do you prevent it?" (Optimistic locking or a single-writer partition per driver.)
  • Deep dive: Read the Ride-Sharing case study

8. Design a Video Streaming Service (e.g., YouTube/Netflix)

Focuses heavily on storage, bandwidth, and edge delivery — the question where the estimation step actually changes the design the most.

  • Core challenge: Uploading, transcoding, storing, and serving massive video files to millions of concurrent viewers.
  • How to approach it: Do the bandwidth math early — it justifies everything else. Separate the upload path (chunked upload → object storage → async transcoding pipeline on a queue) from the serving path (CDN serves nearly everything; origin is the exception, not the rule). Adaptive bitrate (HLS/DASH) is the key serving concept: the client switches quality per-segment based on measured bandwidth.
  • Key concepts: CDNs and cache hierarchy, transcoding as an async worker pool, blob/object storage, metadata database kept separate from video bytes, pre-warming caches for predictable hits.
  • Likely follow-up: "A new episode drops at midnight and 10M people press play — what breaks first?"
  • Deep dive: Read the Video Streaming case study, then compare with the Netflix architecture example.

9. Design a Search Autocomplete System

Tests your knowledge of specialized data structures and latency budgets — suggestions must appear between keystrokes, so you have perhaps 100 ms end to end.

  • Core challenge: Returning ranked search suggestions within milliseconds as the user types.
  • How to approach it: A trie with pre-computed top-K suggestions stored at each node — computing top-K at query time is too slow, and saying so is the insight the interviewer wants. Split the system into a data-gathering pipeline (aggregate query logs, rebuild the trie offline, ship snapshots) and a serving layer (read-only, replicated, cache-friendly).
  • Key concepts: Tries (prefix trees), top-K precomputation, sampling query logs instead of counting everything, CDN/edge caching of popular prefixes, client-side debouncing.
  • Likely follow-up: "How do fresh, trending queries show up if the trie rebuilds daily?" (A small real-time layer merged with the batch layer at query time.)
  • Deep dive: Read the Search Autocomplete case study

10. Design an E-commerce Checkout System

Focuses on transactional integrity and consistency — the anti-pattern question, where "just cache it" answers go to die.

  • Core challenge: Ensuring users can reliably place orders, process payments, and update inventory without overselling — across multiple services that each own their own data.
  • How to approach it: This is a distributed transactions question in disguise. Two-phase commit is the textbook answer and the wrong one at scale (blocking, coordinator failure); the modern answer is the Saga pattern — a sequence of local transactions with compensating actions (reserve inventory → charge payment → confirm; on failure, release the reservation). Idempotency keys on the payment call are non-negotiable: retries must never double-charge.
  • Key concepts: ACID vs BASE, 2PC and its failure modes, Saga orchestration vs choreography, idempotency keys, inventory reservation with TTLs, exactly-once payment semantics.
  • Likely follow-up: "The payment succeeded but your confirmation write failed — what does the user see, and what reconciles it?"
  • Deep dive: Read the Payment System case study, then compare with the e-commerce checkout architecture.

How to Prepare (Beyond Memorizing This List)

Interviewers rotate questions, but the underlying components don't change: every question above is assembled from the same ~15 building blocks — load balancing, caching, sharding, replication, queues, consensus, rate limiting. If you understand the blocks, a question you've never seen is just a new arrangement.

That's the fastest preparation strategy:

  1. Learn the blocks in sequence — the System Atlas curriculum is ordered so each chapter builds on the last, from fundamentals through the case studies linked above.
  2. Build intuition interactively — all 21 simulations are free, no account needed. Watching a cache eviction policy or a consistent-hash ring rebalance while you change its parameters sticks in a way that reading never does.
  3. Practice the delivery — run the 4-step framework out loud against each question on this list, 35 minutes each.

👉 Start the System Atlas curriculum — a deliberate sequence through distributed systems, instead of another content rabbit hole.