System design
System design interview questions
The classic “design X” prompts, each worked end to end the way a senior interviewer expects: clarify the requirements, size the system, sketch the data model and API, draw the high-level design, then deep-dive the decisions that separate a hire from a no-hire. Start with an entry-level prompt and work up.
All system design problems
Design a Parking Lot
Design a parking lot: the object model, spot/vehicle types, assignment strategy, ticketing and fees, and how to extend it to multiple levels.
Entry~35 minDesign a URL Shortener (TinyURL / Bit.ly)
Design a URL shortener (TinyURL) step by step: requirements, scale math, the short-code generation strategy, schema, caching, and redirect path.
Entry~35 minDesign a Distributed Cache (Redis / Memcached)
Design a distributed cache (Redis/Memcached): sharding with consistent hashing, eviction policies, write strategies, invalidation, and hot-key handling.
Mid~40 minDesign a Notification System
Design a notification system that sends push, SMS, and email at scale: fan-out, queues, retries, dedup, rate limiting, and user preferences.
Mid~40 minDesign a Rate Limiter
Design a distributed rate limiter: fixed vs sliding window, token bucket vs leaky bucket, where to enforce it, and how to keep counters consistent.
Mid~35 minDesign a Real-Time Leaderboard
Design a real-time leaderboard: ranking with sorted sets, top-k and rank queries, handling millions of players, sharding, and percentile ranks.
Mid~35 minDesign Search Autocomplete (Typeahead)
Design search autocomplete (typeahead): trie-based suggestions, ranking by popularity, caching, low-latency serving, and updating from query logs.
Mid~40 minDesign a Chat System (WhatsApp / Messenger)
Design a chat system (WhatsApp/Messenger): real-time delivery over WebSockets, message storage, online presence, ordering, and group fan-out.
Senior~45 minDesign a Distributed Key-Value Store
Design a distributed key-value store (Dynamo-style): consistent hashing, replication, quorum reads/writes, conflict resolution, and the CAP tradeoff.
Senior~45 minDesign a News Feed (Facebook / Twitter Timeline)
Design a news feed (Facebook/Twitter): fan-out on write vs read, the celebrity problem, feed ranking, caching, and how to keep the timeline fast.
Senior~45 minDesign a Payment System
Design a payment system: idempotent charges, the ledger and double-entry accounting, reconciliation, async settlement, and exactly-once correctness.
Senior~45 minDesign a Ride-Sharing Service (Uber / Lyft)
Design a ride-sharing service (Uber/Lyft): real-time location updates, geospatial matching, driver-rider pairing, surge pricing, and trip lifecycle.
Senior~45 minDesign a Video Streaming Service (YouTube / Netflix)
Design a video streaming service (YouTube/Netflix): upload and transcoding pipeline, adaptive bitrate, CDN delivery, metadata, and the watch path.
Senior~45 minDesign a Web Crawler
Design a web crawler: the URL frontier, politeness, deduplication, distributed fetching, content storage, and avoiding crawler traps at web scale.
Senior~45 min
How to approach any system design interview
Every prompt above follows the same seven-step structure, and learning the structure is more valuable than memorising any single design. The biggest mistake candidates make is jumping straight to drawing boxes. Instead, open by clarifying scope: what features are in and out, what scale we are designing for, and which non-functional properties matter most. A payment system is dominated by correctness; a news feed by read latency; a web crawler by politeness and deduplication. Naming that priority early tells the interviewer you design for requirements rather than reciting a generic template.
Next, do back-of-the-envelope math. You do not need precision, you need to identify the hard part. If reads outnumber writes a hundred to one, the conversation should centre on caching and replication; if writes spike a hundredfold during an event, it should centre on queues and buffering. Then propose a minimal data model and a small API, sketch the happy-path architecture, and only then start optimising. Optimising before you have a working high-level design is a common way to run out of time with nothing coherent on the board.
Where the interview is actually won
The deep dives are where strong candidates pull ahead. Once the high-level design is on the board, the interviewer probes the decisions that carry real weight: fan-out on write versus read for a feed, token bucket versus leaky bucket for a rate limiter, consistent hashing and quorum tuning for a key-value store, idempotency and a double-entry ledger for payments. These are not trivia. Each one has a tradeoff, and the signal the interviewer is reading is whether you can name the tradeoff, pick a side, and justify it against the requirements you set at the start. Saying “it depends” and then explaining what it depends on is a strong answer; saying it and stopping is not.
Finish by talking about how the design breaks. Identify the bottleneck (a single counter, a celebrity account, a hot cache key, a provider outage) and the specific mitigation. The same handful of building blocks reappear across every problem, which is why the system design cheat sheet is worth internalising: load balancing, caching, sharding, replication, consistent hashing, the CAP theorem, message queues, and the consistency models. Learn those once and most “design X” questions become a recombination of pieces you already understand.