System design
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.
Design a parking lot: the object model, spot/vehicle types, assignment strategy, ticketing and fees, and how to extend it to multiple levels.
Design a URL shortener (TinyURL) step by step: requirements, scale math, the short-code generation strategy, schema, caching, and redirect path.
Design a distributed cache (Redis/Memcached): sharding with consistent hashing, eviction policies, write strategies, invalidation, and hot-key handling.
Design a notification system that sends push, SMS, and email at scale: fan-out, queues, retries, dedup, rate limiting, and user preferences.
Design a distributed rate limiter: fixed vs sliding window, token bucket vs leaky bucket, where to enforce it, and how to keep counters consistent.
Design a real-time leaderboard: ranking with sorted sets, top-k and rank queries, handling millions of players, sharding, and percentile ranks.
Design search autocomplete (typeahead): trie-based suggestions, ranking by popularity, caching, low-latency serving, and updating from query logs.
Design a chat system (WhatsApp/Messenger): real-time delivery over WebSockets, message storage, online presence, ordering, and group fan-out.
Design a distributed key-value store (Dynamo-style): consistent hashing, replication, quorum reads/writes, conflict resolution, and the CAP tradeoff.
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.
Design a payment system: idempotent charges, the ledger and double-entry accounting, reconciliation, async settlement, and exactly-once correctness.
Design a ride-sharing service (Uber/Lyft): real-time location updates, geospatial matching, driver-rider pairing, surge pricing, and trip lifecycle.
Design a video streaming service (YouTube/Netflix): upload and transcoding pipeline, adaptive bitrate, CDN delivery, metadata, and the watch path.
Design a web crawler: the URL frontier, politeness, deduplication, distributed fetching, content storage, and avoiding crawler traps at web scale.
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.
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.