System Design Interview Problems
Full walkthroughs of the canonical system design interview questions. Requirements, scale estimates, architecture, deep dives, trade-offs, and lessons to study before you walk in.
System Design Interviews at Indian Companies
Preparing for system design rounds at Flipkart, Paytm, PhonePe, Swiggy, Zomato, Razorpay, Zerodha, CRED, Meesho, Ola, or Zepto? These walkthroughs cover the exact products they build, with the real scale numbers, architecture, and trade-offs Indian interviewers actually probe.
Design Razorpay
Designing Razorpay is the India-specific payment problem: you have to talk about UPI rails, NPCI integration, the differences between Cards, Net Banking, UPI, and wallets, and the regulatory environment (RBI, tokenization mandates). It tests whether you understand what makes Indian payments uniquely demanding: collect requests, virtual payment addresses, and the 60+ banks that all need to settle.
Design CRED
Designing CRED is a fintech problem with three distinctive parts. First, membership is gated: a user can only join if their credit score clears a threshold, which is checked at onboarding against credit bureaus, so access control is part of the design rather than an afterthought. Second, the core action is paying a credit-card bill, which is an orchestrated money movement that CRED runs through a central order management system built on state machines and events. Third, the load is cyclical, concentrated around monthly billing due dates. This walkthrough centers on the order management system that CRED has published, the gated onboarding, and how the platform handles the monthly spike, and is honest about which payment and reconciliation details are the standard fintech pattern rather than CRED-published.
Design Dream11
Designing Dream11 is the extreme-spike problem. The load is not smooth: for a popular match, a large share of the day's users create or edit their fantasy teams in the last few minutes before the deadline, and the toss right before the match makes everyone act at once. On top of that, once the match starts, the platform has to score every user's team from live ball-by-ball data and update the ranks across thousands of contests for millions of players, continuously. The interview is about absorbing a predictable but enormous surge, keeping contest joins and money correct under that load, and fanning live scores out to huge leaderboards. Note that Dream11 paused paid contests in August 2025 after a change in Indian law, so this describes how the platform was engineered during its paid-contest era.
Design Flipkart
A complete system design walkthrough of an e-commerce platform like Flipkart, built for India's Big Billion Days. We cover the read-heavy catalog and search path, the write-heavy checkout path, how inventory stays consistent without overselling during flash sales, cart reservation with TTLs, the order-management state machine (Flipkart's open-source Flux), and how to absorb a thundering herd with virtual waiting rooms, rate limits, and queues.
Design Groww
Designing Groww is the mass-market investing problem. Groww grew fast to become India's number one broker by active clients, largely by making investing simple on a mobile app for first-time investors, and by running several products, mutual funds, systematic investment plans, stocks, futures and options, and UPI payments, behind one app. The engineering that Groww has published is distinctive: a move from MySQL to a distributed, cell-based database for horizontal scale, a high-performance trading terminal that streams market data as compact binary messages, and serious reliability engineering around the daily market open. This walkthrough centers on those published parts and the mass-market scale, and is honest that the exchange-connectivity plumbing is the standard broker pattern rather than a Groww-published design.
Design JioHotstar
A deep, interview-grade walkthrough of designing a live video streaming platform at India scale: adaptive bitrate (HLS/DASH), multi-CDN with origin shielding, the extreme traffic dynamics of a cricket wicket, and why you pre-warm and predictively scale instead of trusting reactive autoscaling. Grounded in how Hotstar actually handled its record-breaking IPL and World Cup peaks.
Design IRCTC
Designing IRCTC is the fixed-inventory, fixed-time-spike problem at national scale. Every train has a bounded number of seats, split across quotas like general and Tatkal, and the Tatkal quota opens at a fixed minute, 10 AM for air-conditioned classes and 11 AM for others, so a huge crowd hits a scarce pool at exactly the same moment. The system must sell each berth once and only once under that pressure, handle waitlist and reservation-against-cancellation states, and hold off bots trying to grab seats faster than people. IRCTC and the railways body that runs the reservation backend publish capacity and record numbers but not the internal seat-locking design, so this walkthrough reasons about the fixed-inventory contention from first principles and is clear about what is stated versus inferred.
Design Meesho
Designing Meesho is an e-commerce problem with a different shape from the usual one. Its users are largely first-time online shoppers in tier-2, tier-3, and smaller towns who browse a personalized feed in their own language rather than searching for a product by name, so the home screen is a recommendation problem, not a search box. The baskets are small and the order volume is enormous, which makes cost per order the number that decides whether the business works, so the engineering is obsessed with efficiency. This walkthrough centers on the discovery feed and the machine-learning platform behind it, both of which Meesho has published, on the low-cost-per-order economics, and is honest about which parts of the order path are the standard e-commerce pattern.
Design Nykaa
Designing Nykaa is an omnichannel commerce problem with a beauty-specific twist. Unlike a pure marketplace, Nykaa buys, holds, and curates its own beauty inventory to control authenticity, which matters in a category full of counterfeits, while running a marketplace model for fashion. It sells through a website, an app, and hundreds of physical stores, so a single view of inventory across warehouses and stores is central. Discovery is content-led rather than purely search-led, and the whole business runs on a unified data platform. This walkthrough covers the hybrid retail model, omnichannel inventory, content-driven discovery, and the data platform Nykaa has published, and is honest that Nykaa releases little about its transactional serving stack, so those parts are described as the standard pattern.
Design Ola
Designing Ola is the ride-hailing problem with an India twist. The core is the same shape as any ride-hailing app: a rider requests a car, the system finds a good nearby driver, both sides track the trip live, and payment settles at the end. What makes Ola distinctive, and what it has actually published, is the mapping layer underneath. Ola built its own maps, routing, and estimated-time-of-arrival stack for Indian roads, because global map providers did not serve India well, and it uses its own vehicle fleet as a rolling sensor network to keep the maps fresh. This walkthrough covers the ride-hailing core as the standard pattern, and goes deep on the Ola Maps stack, which is the part Ola has documented.
Design Paytm
Designing Paytm is the canonical India payments problem. You have to move real money between two banks over the NPCI UPI rails, keep a double-entry ledger that always balances, make every operation idempotent so a retry never double-charges, reconcile against the bank end-of-day, and survive a Diwali sale spike that is 5 to 10x a normal Tuesday. It is less about clever algorithms and more about correctness under failure.
Design PhonePe
Designing PhonePe is the India payments problem at national scale. You have to move real money over the NPCI UPI rails without ever creating or losing a rupee, make every step idempotent so a retry never double charges, and reconcile against the bank when a callback arrives late. On top of that correctness core, PhonePe is a study in scaling: a shared-nothing sharded MySQL ledger, an Aerospike layer serving real-time reads and fraud checks at very high throughput, a Kafka backbone carrying about 100 billion events a day, and its own on-premises data centers. The interview is as much about horizontal scale and availability as it is about money.
Design Swiggy
Designing Swiggy means solving three coupled problems at once: serviceability (which restaurants can even reach this customer), dispatch (which delivery partner picks up which order, often batched), and a three-party order state machine that survives a restaurant rejecting an order, a partner going offline mid-trip, or a payment webhook arriving late. The hard part is that almost all of the load lands in two short meal peaks, so the system is sized for 4-5x its average and idle the rest of the day.
Design Zepto
Designing Zepto is the quick-commerce problem, which is different from food delivery. Zepto does not pick from restaurants or third-party shops; it stocks its own small warehouses, called dark stores, placed close to customers, and delivers in about 10 minutes. That promise drives everything: dense stores, a small curated set of high-demand products, in-store picking in under 75 seconds, and real-time inventory per store so it never sells what a specific store does not have. This walkthrough centers on the dark-store model and the data architecture Zepto has published, including a purpose-built order pipeline that splits fast draft orders from durable confirmed orders, and is honest that the store-placement and dispatch details are the general quick-commerce pattern.
Design Zerodha
Designing Zerodha is the real-time trading problem. You have to stream live market prices to hundreds of thousands of users at once with very low latency, take an order from a phone and route it to the exchange and back through an order management system, keep positions and funds correct to the paisa, and survive the enormous spike at the 9:15 market open. It is also a lesson in restraint: Zerodha runs this at national scale on a small team with few services, a Postgres-first design, and Redis holding the hot data in memory. The interview rewards both the real-time streaming design and the judgment to keep the system simple.
Design Zomato
Designing Zomato is the hyperlocal food delivery problem at India scale. You have to decide which restaurants can actually reach an address in milliseconds, place and track an order through a state machine shared by the customer, the restaurant and the delivery partner, assign and batch delivery partners efficiently, and predict a delivery time the customer can trust while the kitchen, the traffic and even the weather keep changing. The constraint that shapes everything is that most of a day's two million orders arrive in two short meal windows, so the system has to be built for a spike that is many times its daily average.
Global Products & Core System Design
The canonical questions asked at Google, Meta, Amazon, Uber, Netflix, and the AI labs, from URL shorteners and news feeds to RAG systems and vector databases.
Design DynamoDB (a distributed key-value store)
DynamoDB is a managed distributed key-value and document store descended from the 2007 Amazon Dynamo paper. You address every item by a primary key, and the system hashes that key to decide which partition, and therefore which set of storage nodes, owns the item. Data is partitioned by consistent hashing and replicated to a small number of nodes (typically three) across separate availability zones, so a single node or even a whole zone can fail without losing data or availability. The original Dynamo was fully leaderless and used vector clocks with application-side conflict resolution, but production DynamoDB moved to a per-partition leader with quorum-style replication and a write-ahead log, which is simpler for developers to reason about. Reads come in two flavors: eventually consistent (cheap, may be slightly stale) and strongly consistent (routed to the leader replica). The hard design themes are all trade-offs: how you pick a partition key so load spreads evenly instead of creating a hot partition, how the system reshares and moves data online as tables grow, how secondary indexes are kept up to date asynchronously, and how global tables give you multi-region writes at the cost of last-writer-wins conflict resolution. DynamoDB leans toward availability and predictable latency over rich query power and strong global consistency.
Design Time-Series Database (a purpose-built store for timestamped metrics)
A time-series database (TSDB) is a store optimized for data that is a sequence of timestamped values, such as CPU usage, request latency, sensor readings, or stock prices. Instead of thinking in rows and joins, it thinks in series: a metric name plus a set of key-value tags (labels) uniquely identifies one series, and each series is an ordered stream of (timestamp, value) points. Writes are append-heavy and mostly in timestamp order, reads are heavily skewed toward recent data, and queries are dominated by range scans and time-bucketed aggregations rather than point lookups. This workload breaks the assumptions of a general-purpose relational row store, so a TSDB makes different choices: it stores points columnar and per-series so that a scan touches only the columns and time ranges it needs, it compresses hard using delta-of-delta encoding on timestamps and XOR (Gorilla-style) encoding on floats to get roughly an order of magnitude reduction, and it partitions data by time so old data can be dropped or downsampled in bulk. Ingestion typically flows through a write-ahead log for durability and an in-memory head block for recent points, which is periodically flushed to immutable on-disk blocks. The central failure mode is cardinality: because every unique tag combination is a new series, a single high-cardinality label (a user id, a request id, a container id that churns) can explode the series count and blow up memory and index size. Retention and downsampling (raw to 1-minute to 1-hour rollups) keep long-term storage affordable, and the query engine adds time-series-native functions like rate, percentiles, and group-by-time. TSDBs lean toward cheap high-volume ingestion and fast recent-range queries, and away from arbitrary updates, cross-series joins, and unbounded cardinality.
Design API Design (designing a public HTTP/RPC API)
API design is the practice of defining the contract between a service and its callers: the resources it exposes, the operations allowed on them, the shape of requests and responses, the error format, and the rules for authentication, versioning, and evolution. The three dominant styles are REST over HTTP (resource-oriented, cacheable, ubiquitous), GraphQL (a single endpoint with a typed query language that lets clients ask for exactly the fields they need), and gRPC (contract-first binary RPC over HTTP/2, fast and strongly typed, ideal for internal service-to-service calls). Most of the hard problems are the same regardless of style. You have to model resources and name them consistently, choose HTTP methods and status codes that mean what they say, decide how to version without breaking existing clients, paginate large collections without offset drift, make write operations idempotent so retries are safe, return machine-readable errors in a standard format such as RFC 7807 problem+json, authenticate and authorize callers, and defend the service with rate limits and quotas. Good API design leans hard toward backward compatibility, predictability, and least surprise, because the cost of a breaking change is paid by every integrator at once and cannot be undone unilaterally.
Design a Machine Learning System
Machine learning system design is a distinct interview format from classic system design. You are still expected to talk about services, storage, and scale, but the spine of the answer is the ML lifecycle: frame the problem, define metrics, get and label data, engineer features, pick a model, train it, evaluate it offline, ship it behind an A/B test, serve it within a latency budget, and monitor it for decay. A strong candidate starts by clarifying the business goal and deciding whether machine learning is even the right tool, since a rules-based or heuristic baseline is often the honest first answer. Then they translate the business goal into a concrete ML objective and separate the offline metric they train against from the online metric the business actually cares about, because those two rarely move together perfectly. The data section is where interviews are won or lost: where labels come from, how to avoid leakage, how to handle class imbalance, and how to prevent the train-serve skew that happens when features are computed one way in the training pipeline and a different way at serving time. That last problem is exactly what a feature store exists to solve. For the model itself, the disciplined move is to establish a simple baseline before reaching for anything complex, and for recommendation, search, and feed ranking (the most common ML design prompt) to use the two-stage candidate-generation-plus-ranking pattern that narrows millions of items down to a few hundred cheaply, then scores those precisely. Offline evaluation tells you whether a model is promising; only an online A/B test tells you whether it actually helps. Serving splits into batch (precompute predictions on a schedule) and online (compute on request), each with different latency and freshness trade-offs. Finally, the system needs monitoring for data drift and model decay, because an ML system that is not watched will silently get worse. The candidates who stand out are the ones who treat the model as the easy part and the platform around it (feature stores, low-latency serving, drift monitoring, retraining) as the hard part, because in production that is exactly where the difficulty and the value live.
Design RAG System
Retrieval-augmented generation sounds simple, look up relevant text and paste it into an LLM prompt, but nearly every hard decision is hidden in that sentence. You have to split documents into chunks (how big, how much overlap, split on what boundary), embed them with a model you must then use identically at query time, and store the vectors in an index whose parameters trade recall against latency. At query time you decide between pure vector search and a hybrid of dense plus keyword search, whether to rerank the survivors with a slower cross-encoder, and how to fit the best chunks into a fixed token budget without burying the answer in the middle. Then you owe the user a grounded answer: the model must respond from the retrieved context and cite it, not hallucinate, which pushes you into prompt design, guardrails, and evaluation. On top of that sit the operational realities, keeping the index fresh as documents change, re-embedding the whole corpus when you switch models, filtering retrieval by tenant and permissions, and measuring retrieval quality and faithfulness rather than guessing. A strong answer treats the LLM call as the easy part and spends its time on chunking, retrieval quality, grounding, freshness, and cost.
Design ChatGPT
Designing ChatGPT looks like designing a chat app until you notice the model is stateless and the GPU is the entire problem. Every turn resends the whole conversation, so the model reprocesses the full history to produce the next reply, and the cost of a conversation grows as it gets longer. Inference itself splits into two phases with opposite bottlenecks: prefill reads the prompt in parallel and saturates compute, while decode emits one token at a time and is limited by memory bandwidth, because each token has to re-read the model weights. That asymmetry drives nearly every decision. The KV cache that makes decode affordable is also what fills the GPU, so PagedAttention borrows virtual-memory paging to stop fragmentation from wasting most of the card, and continuous batching swaps finished sequences out at each iteration instead of waiting for the slowest one. Prefix caching turns a shared system prompt and a repeated conversation history into a cache hit rather than recomputation. Speculative decoding exploits the fact that verifying several tokens costs about the same as generating one. Then the product layer adds its own constraints: streaming so the answer starts before it is finished, moderation on both the input and the streaming output, token-based quotas rather than request-based ones, and routing that treats a GPU holding long conversations as full even when its request count looks low. The chat CRUD is a weekend project. The interview is about GPU memory, batching, and the latency budget.
Design an AI Agent
Wire a model to a few tools and you have something that looks like an agent; run it on a real task and the loop is where every hard problem surfaces. The model does not execute anything itself; it emits a request to call a tool, an orchestrator runs the tool, and the result is fed back for the next decision, over and over. The first thing that bites is reliability, because a chain of steps multiplies its per-step error rate, so the design has to add verification, retries, and bounded scope to stop a long task from almost certainly failing. The second is state, because an agent run is long enough to outlive the process running it, which turns it into a durable-execution problem closer to a workflow engine than to a web request: you record each step so a crash resumes instead of restarting. The third is memory, since the growing transcript is both the agent's working memory and its biggest cost, so you decide what to keep in the context window, what to push to a store and retrieve later, and what to summarize. The fourth is safety, and it is sharper than in a plain chatbot because the agent can act: a tool can send money or delete a file, and the untrusted text a tool returns can carry a prompt injection that hijacks the next decision, so tools run with least privilege and irreversible actions wait for a human. Cost ceilings, loop detection, parallel tool calls, and trajectory-level evaluation ride on top of all of it. Get the control loop and its guardrails right and the agent ships; get them wrong and no starting prompt will save it.
Design Rate Limiter
The job sounds trivial, count requests per key and reject once the count crosses a limit, but almost everything hard is hidden in that sentence. You have to decide what a key is (user, IP, API key, or a tuple of endpoint and user), where the check runs (client, gateway, or service), and which algorithm to use (fixed window, sliding window log, sliding window counter, leaky bucket, or token bucket), each with a different memory and burst profile. The moment you run more than one limiter node, the counter has to live in shared state, usually Redis, and the read-modify-write becomes a race condition that lets requests slip through unless you make it atomic with a Lua script or an atomic INCR. Then you decide what happens when the shared store is slow or down, fail open and let traffic through, or fail closed and reject. On top of that you owe the caller a clean contract: a 429 status, a Retry-After header, and headers that tell them how many calls remain. A good answer treats the algorithm as the easy part and spends its time on atomicity, propagation delay, burst handling, and the failure modes.
Design Online Judge
An online judge accepts source code, runs it against a set of hidden test cases, and returns a verdict such as Accepted, Wrong Answer, Time Limit Exceeded, or Memory Limit Exceeded. The hard part is not the web app. It is executing untrusted code safely and cheaply at high concurrency. A submission is accepted quickly, persisted, and dropped onto a queue, then a pool of judge workers pulls jobs and runs each one inside a locked-down sandbox with hard limits on CPU time, wall time, memory, process count, and output size. The judge compiles the code, runs it test by test against stored inputs, compares output to the expected answer with a checker, and emits the first failing verdict. Results flow back through a results channel that the client polls or receives over a websocket. The interesting design pressure comes from contests, where a synchronized burst of submissions creates a thundering herd on the queue and the worker pool, and from security, where a single sandbox escape leaks every hidden test on the machine. Good answers treat isolation, back-pressure, and fair scheduling as first-class, not as an afterthought.
Design Code Deployment System
A code deployment system takes a commit and carries it all the way to production: it builds the code, runs tests, produces an immutable artifact, stores that artifact, distributes it to every target host, and then flips traffic over in a controlled way. The design splits cleanly into a control plane that decides what should run where, and a data plane that actually moves bytes and swaps processes on each machine. The interesting engineering lives in two places. First, distribution: pushing a large artifact to tens of thousands of hosts from a central store saturates the origin, so real systems use peer to peer swarms or a tree of regional caches so that hosts pull from each other. Second, safety: you never flip all hosts at once, you use rolling, blue-green, or canary strategies with automated health checks and metric comparison so a bad build is caught on a small blast radius and rolled back fast. Everything hinges on immutable, versioned artifacts and a deployment state machine that can always answer what version is on which host and can drive it back to a known good version.
Design Recommendation System
The interview is really about a funnel. You cannot score billions of candidate items with an expensive model on every request, so you split the work into stages. A retrieval or candidate generation stage cuts the catalog from billions down to a few hundred or a few thousand cheaply, usually with a two-tower model whose item embeddings are precomputed and indexed for approximate nearest neighbor search. A ranking stage then scores that short list with a heavier model that can afford richer user-item cross features. Behind both sits a feature store that serves the same feature values online at request time and offline during training, so the model sees consistent inputs. A streaming pipeline turns clicks, watches, likes, and skips into fresh features and training labels. The recurring themes an interviewer probes are the latency budget across stages, how you keep offline and online features in sync, how you handle cold start for new users and new items, and how you measure whether a change actually helped through A/B testing rather than offline metrics alone.
Design Distributed Counter
A distributed counter looks trivial until you notice that popularity is not evenly distributed. Most counters are cold, but a handful go viral and take a firehose of concurrent increments. The core problem is write contention on a single hot key, because consistent hashing maps one key to exactly one node no matter how large the cluster is. The standard answer is to stop storing the count as one value. You either shard the counter into N sub-counters and sum them on read, buffer increments in memory and flush batched deltas, or model the counter as a CRDT so replicas merge without coordination. Reads and writes get very different treatment: writes must be cheap and absorb bursts, while reads tolerate a slightly stale number because nobody notices if a like count is off by a few for a second. For unique counts like distinct viewers you switch to a probabilistic structure such as HyperLogLog. Durability comes from a persistent store behind a fast cache, and time-windowed counts fall out of bucketing events by time. The whole design is an exercise in trading exact, immediate consistency for write throughput and availability.
Design API Gateway
An API gateway is the single entry point that sits between external clients and a fleet of internal microservices. It terminates TLS, authenticates and authorizes each request, applies rate limits and quotas, routes to the correct upstream based on path or host or headers, and often transforms or aggregates responses before returning them. The hard part is that it is on the critical path for every request, so it must be fast, non-blocking, and horizontally scalable without becoming a single point of failure. Good designs treat the gateway as a thin, stateless, policy-enforcing proxy built around a chain of composable filters or plugins, with heavy work (business logic, data ownership) pushed back into the services. The interview is really about where responsibility belongs: what the gateway should own versus what it must never own. Candidates who put too much logic in the gateway rebuild a distributed monolith with a new name. The reference implementations to reason from are Netflix Zuul 2, Kong, Envoy, and AWS API Gateway, each of which models the request lifecycle as an ordered set of pluggable stages.
Design Zoom
Zoom is a real-time video conferencing system, and the whole design turns on one decision: how do you get every participant's camera and microphone to everyone else in a meeting without melting a server or a laptop. A full mesh where each client sends directly to every other client scales as N squared and dies past a handful of people. An MCU that decodes, mixes, and re-encodes one combined stream per participant is CPU-brutal and adds latency. Zoom, like most modern systems, uses a Selective Forwarding Unit: each client uploads one stream, the media router forwards the right copies down to each receiver, and no decoding or mixing happens on the server. Clients help by sending simulcast, meaning several quality layers of the same camera at once, so the router can hand a weak connection a low bitrate copy and a strong one the full resolution. Media rides UDP because a late packet is worse than a lost one, and the app leans on jitter buffers, forward error correction, and adaptive bitrate to survive real networks. Signaling, region selection to the nearest data center, large-meeting fanout, and cloud recording all sit around that media core.
Design Twitch
Twitch is a live video platform, which makes it a very different design problem from Netflix or YouTube VOD. A broadcaster pushes one live RTMP stream, and Twitch has to accept it at a nearby point of presence, route it to an origin, transcode it into multiple renditions in real time, package it as HLS segments, and push those segments through a CDN to potentially millions of viewers, all while keeping glass-to-glass latency in the low single digit seconds. On top of that sits a real-time chat system that has to deliver a firehose of messages per channel with strict ordering and moderation. The hardest parts are the transcode fleet economics, the thundering herd when a huge streamer goes live and every viewer requests the first segment at once, keeping live latency low without breaking CDN cacheability, and building a chat fanout tier that can hold tens of millions of persistent connections. Twitch built custom systems for most of this, including Intelligest for ingest routing and a purpose built transcoder, and a Go based chat edge and pubsub layer. A good interview answer separates the video plane from the chat plane and treats them as two independent scaling problems that happen to share a channel identity.
Design Leaderboard
A leaderboard looks trivial until you attach real numbers to it. The core data structure that makes it tractable is the sorted set, a collection kept in score order that supports O(log N) inserts, O(log N) rank lookups, and O(log N + M) range reads. Redis implements this with a skip list for ordering plus a hash table for O(1) score lookup, which is why ZADD, ZREVRANK, and ZREVRANGE all stay fast even with millions of members. The read path splits into two very different queries: the global top-N, which is cheap because it is one bounded range read, and the 'my rank' query for an arbitrary user, which is the expensive one because it must be answered for every viewer. Writes are heavy and bursty during events, so you buffer and batch score updates and use atomic ZINCRBY to avoid read-modify-write races. As the member count grows past what one node can hold, you shard, and sharding a single global ranking is genuinely hard because Redis Cluster does not split one sorted set across nodes. You either shard by score range, or hash members across shards and merge per-shard results, or fall back to approximate ranks for the deep middle of the board. Time-windowed boards (daily, weekly, all-time) are separate keys with TTLs. The design is a study in picking exact ranks where they matter and approximate ranks where they do not.
Design Stock Exchange
A stock exchange is a low-latency deterministic matching system, not a CRUD app. Orders arrive over gateways, get validated and risk-checked, then flow into a single sequenced input stream that assigns each event a monotonic sequence number. A single-threaded matching engine consumes that stream and applies each order to an in-memory limit order book, which keeps resting orders sorted by price and, within a price level, by arrival time. Matching follows price-time priority: the best price trades first, and ties break by who got there earliest. Because every replica consumes the exact same ordered input and the engine is deterministic, all replicas compute byte-identical output, so recovery and hot standby become replay problems rather than distributed-consensus problems on the hot path. Durability comes from journaling the sequenced input to an append-only log before or in parallel with matching, in the style of the LMAX Disruptor. Fills and book changes fan out as a market data feed with periodic snapshots plus incremental deltas. The design goal is microsecond-scale, jitter-free matching with zero data loss and provable determinism.
Design Uber Eats
Uber Eats is a three-sided real-time marketplace. Eaters open the app at a delivery address and expect a ranked list of nearby restaurants that can actually deliver to them quickly, which makes search fundamentally geospatial rather than purely lexical. When an order is placed, the platform runs a distributed transaction across payments, the restaurant point-of-sale, and courier dispatch, then keeps everyone updated with a live map. The hardest parts are dispatch and timing: the system has to predict how long the food will take to cook, when a courier will reach the restaurant, and how long the final leg to the eater will take, then solve a global assignment problem that pairs orders with couriers to minimize total wait and keep food hot. On top of that sit geo-sharded search indexes, streaming location pipelines, surge pricing during demand spikes, and a payment split that pays the restaurant, the courier, and captures Uber's fee. A good design separates the read-heavy discovery path from the write-heavy order and dispatch path, and treats ETA prediction as a first-class machine learning system rather than a fixed constant.
Design Google Search
Google Search is two loosely coupled systems joined by a data structure. The offline half crawls the web, parses pages, and builds an inverted index that maps every term to the list of documents containing it, sharded across thousands of machines. The online half takes a user query, resolves it against every index shard in parallel, scores the candidate documents with PageRank plus hundreds of other signals, and merges the top results. The central tension is scale versus latency: the index is far too large for one machine, so it is partitioned by document into shards that are each replicated many times, and a query fans out to all shards at once in a scatter-gather pattern. Because a single slow shard would stall the whole query, the serving path leans on in-memory posting lists, tight per-stage timeouts, hedged requests, and partial-result tolerance. On top of that sits a snippet-generation stage, a heavy caching layer for popular queries, an autocomplete service that predicts the query before it is finished, and an incremental indexing pipeline that keeps fresh pages searchable within seconds.
Design Notification System
A notification system takes an event, such as "your driver is arriving" or "someone commented on your post," and turns it into one or more messages delivered across the right channels to the right users. The hard part is not sending one push; it is doing this reliably for billions of events a day while respecting user preferences, deduplicating retries, rate limiting per user and per channel, and tracking delivery status end to end. The standard shape is an ingestion API that validates and enqueues requests, a fanout stage that expands an event into per-user per-channel jobs, durable queues that decouple producers from delivery, and channel-specific workers that talk to APNs, FCM, an SMS aggregator like Twilio, and an email provider like SES or SendGrid. Idempotency keys and a dedup store prevent double sends, retries use exponential backoff with jitter, and messages that exhaust retries land in a dead-letter queue for inspection. Priority lanes keep a two-factor code from waiting behind a marketing blast. Templates and user preferences are looked up per message so content is localized and channels the user has muted are skipped.
Design Distributed Job Scheduler
A distributed job scheduler accepts two kinds of work: one-off jobs due at a specific instant, and recurring cron jobs that fire on a repeating expression. The core loop is simple to state and hard to build: durably persist every schedule, efficiently find the ones that are due right now, and dispatch each one exactly when it is due without firing it twice. The design splits into a durable job store partitioned by time, a due-time selection structure (a time wheel, a priority queue, or a ranged index scan over the store), a coordinator that uses leader election to assign time partitions to scheduler nodes so no two nodes fire the same trigger, a dispatch path that hands due jobs to a worker pool through a delayed queue, and an execution store that records attempts and enforces idempotency. Because a scheduler is a distributed system with real clocks, you cannot promise exactly-once execution, so you promise at-least-once dispatch and make the work idempotent through dedup keys. Clock skew, thundering herds at cron boundaries, catch-up runs after an outage, and retry with dead-lettering are the subsystems that separate a toy from something you would trust with billing.
Design Digital Wallet
A digital wallet stores value for a user and lets them top up, withdraw, transfer, and pay while the balance stays exactly correct under retries, crashes, and concurrent access. The heart of the design is a double-entry ledger: money is never created or destroyed, it only moves between accounts, and every transaction is a balanced set of debits and credits that sum to zero. The money path is strongly consistent and ACID, because a lost or duplicated cent is a real financial loss and a compliance problem. Idempotency keys make client retries safe, so a top-up sent twice over a flaky network still moves money once. Holds let you reserve funds during a card authorization and capture or release them later without ever letting the user double-spend the same balance. The balance read path is high-volume and can be served from a cached or precomputed value, which is the central asymmetry you must design around. Multi-currency means every account carries a currency and you never mix them in one posting. Reconciliation runs continuously against banks and payment processors so the internal ledger and the outside world always agree.
Design Google Drive
The core of a Drive-style system is the split between a metadata plane and a data plane. File contents are broken into chunks, hashed, deduplicated, and written to object or block storage that handles replication and durability. A separate metadata database records the folder tree, file versions, chunk lists, permissions, and per-user sync state, and this is the part that must be strongly consistent and low latency. Sync is the hard subsystem: every client keeps a cursor into a per-user change log, and the server tells it only which files changed, not the bytes. When a client does need bytes, delta sync sends only the chunks whose hashes differ from what the client already has. Large uploads are resumable so a dropped connection near the end of a 4 GB file does not restart from zero. Sharing turns one physical file into many logical views through access control lists checked on every read. Concurrent edits from offline clients produce conflicts, which the system resolves by versioning and, for some file types, by forking a conflicted copy rather than silently losing work.
Design Yelp
Yelp is a local discovery product, so the interview is really about geospatial search over a mostly static, read-heavy dataset. You have businesses with a location, categories, hours, price, and a stream of user reviews that roll up into a rating. A query carries a point or a map bounding box plus filters, and you must return the most relevant businesses ranked by a blend of distance, rating, and text match. The core design problem is the spatial index: a plain latitude and longitude B-tree cannot answer 'within N km' efficiently, so you reduce 2D proximity to a 1D or hierarchical key using geohash, a quadtree, or Google S2 cells, and let a search engine like Elasticsearch or Lucene do the filtering and scoring. Ranking is a two-phase retrieve-then-rank pipeline: the search engine recalls a candidate pool cheaply, then a learning-to-rank model reorders it. Everything sits behind read replicas and aggressive caching because the same popular queries and neighborhoods repeat constantly. Writes (new reviews, rating recomputation, business edits) go through a separate path and are indexed near real time.
Design Ticketmaster
A ticketing platform looks simple until one hot event goes on sale and a hundred thousand people fight over forty thousand seats in the same sixty seconds. The core requirement is that a given seat is sold to exactly one buyer, ever, even under massive concurrency, while the site stays up for everyone else. The design has three load-bearing pieces. First, a virtual waiting room that holds and paces arrivals so the booking backend only ever sees traffic it can handle. Second, a reservation model where selecting a seat places a short temporary hold that auto-releases if payment does not complete, so abandoned carts do not lock inventory forever. Third, an idempotent, serialized commit path where the transition from held to sold happens under a lock or a conditional write that a competing request cannot win twice. Around that sit the seat map, the payment integration, and a reconciliation loop that cleans up expired holds. Get the waiting room, the hold expiry, and the atomic sell right, and the rest is standard web engineering.
Design Reddit
A Reddit clone looks simple until you open a busy thread. The core objects are posts, comments, votes, and subreddits, but comments form arbitrarily deep trees that must be stored, ranked, and paginated with a working 'load more comments' path. Ordering is driven by three real algorithms: hot uses a logarithmic vote weight plus a time term so fresh content floats up, best uses the Wilson score lower confidence bound so a comment with 10 of 10 upvotes does not outrank one with 400 of 420, and controversial rewards posts where ups and downs are close and both large. Votes arrive faster than any single Postgres row can absorb, so counting is asynchronous and cached, and Reddit historically fuzzed vote totals to frustrate spam bots. Reads dominate writes by a wide margin, so subreddit and home listings are precomputed and cached rather than queried live. The interesting failure mode is a hot post: a single key gets so much traffic that a cache miss can stampede the origin. Reddit's real history, a schemaless 'thing' plus 'data' store on Postgres, heavy Cassandra use, memcached everywhere, and RabbitMQ for async work, gives you a concrete blueprint to reason from.
Design Tinder
Tinder is a location-based dating app where each user is shown a deck of nearby candidate profiles, swipes right (like) or left (pass) on each, and a mutual right swipe creates a match that opens a chat. The design has three genuinely hard subsystems. First, recommendation retrieval: given a user's location and distance filter, return candidates ranked by relevance, which Tinder solves with geosharding using Google's S2 library so a query touches only a handful of shards instead of a global index. Second, the swipe pipeline: billions of swipes per day are ingested as an ordered stream, left swipes are archived cheaply while right swipes are checked against a likes store to detect the reciprocal like. Third, match detection has to be idempotent and race-free so a simultaneous double right swipe produces exactly one match. Around these sit profile and photo storage on object storage plus a CDN, a match and chat service backed by a durable message store with real-time delivery over persistent connections, and push notifications. The recurring themes are geo-partitioning, write-heavy stream processing, and cache-backed reciprocal lookups.
Design Redis
Redis is an in-memory data structure store that people reach for as a cache, but it is really a small, fast database with server-side data types: strings, hashes, lists, sets, sorted sets, streams, bitmaps, and HyperLogLog. The core is a single-threaded event loop that processes commands sequentially, which removes lock contention and makes every operation effectively atomic without the programmer thinking about it. Because data lives in RAM, latency is dominated by the network round trip rather than disk. Durability is optional and tunable through two mechanisms: point-in-time RDB snapshots and an append-only file (AOF) that logs every write. Availability at scale comes from asynchronous primary-replica replication plus either Redis Sentinel for automatic failover of a single shard, or Redis Cluster, which shards the keyspace across 16384 hash slots and gossips membership between nodes. The hard design questions are all trade-offs: how much data you are willing to lose on a crash or failover, how you handle multi-key operations once keys live on different shards, and whether you can tolerate reading slightly stale data from a replica. Redis leans AP: it favors staying available and fast over guaranteeing that every replica is perfectly in sync.
Design Elasticsearch
Elasticsearch is a distributed search engine built on top of Apache Lucene. The core data structure is the inverted index, which maps each term to the list of documents that contain it, so a full-text query becomes a set of postings-list lookups rather than a scan. A logical index is split into shards, each shard is a self-contained Lucene index, and each shard can have replicas for availability and read throughput. Writes go to an in-memory buffer plus a durable transaction log, then a periodic refresh turns the buffer into a searchable Lucene segment, which is why search is near real-time rather than immediate. Reads fan out to every shard, each shard returns its top matches, and a coordinating node merges those partial results. A master node owns cluster state and shard allocation, and quorum-based election prevents split-brain. The interesting design tension is that Lucene segments are immutable and search wants fresh data, so the engine trades a small refresh delay and background segment merges for high indexing and query throughput.
Design Ad Click Aggregator
An ad click aggregator ingests a massive stream of click and impression events, groups them into per ad, per time bucket counts, and serves two audiences from the same data: advertisers watching a near real time dashboard and a billing system that needs numbers it can defend. The core of the design is a durable log (Kafka) that absorbs the firehose and partitions events by ad id, a stream processor (Flink or Spark Structured Streaming) that runs windowed aggregation over event time, and an OLAP store (Druid, Pinot, or ClickHouse) that holds pre aggregated rollups and answers dashboard queries in well under a second. The hard parts are all about correctness under failure. Events arrive out of order and late, so you need watermarks and a grace period to decide when a minute is done. A click must be counted exactly once, so every event carries a stable id and gets deduplicated. A viral ad creates a hot partition that one consumer cannot keep up with. And because streaming counts can drift, most real systems keep a batch reconciliation path (or a replayable single stream) that produces the authoritative billing number a few hours later. The interview is really a tour of stream processing done under a billing constraint.
Design Google Maps
The problem breaks into four hard subsystems that barely share code. First, geospatial indexing: you have to store points of interest and road geometry for the entire globe and answer 'what is near this lat/long' in milliseconds, which pushes you toward a space-filling-curve index like Google's S2 rather than a naive lat/long B-tree. Second, map rendering: the visible map is a tile pyramid keyed by zoom, x, and y, served mostly from CDN, and modern clients pull vector tiles so the same bytes restyle and rotate on the GPU. Third, routing: plain Dijkstra or A* explores far too many nodes to route across a country, so production systems precompute shortcuts (contraction hierarchies and related techniques) to prune the search to a few hundred nodes. Fourth, ETA and live traffic: phones send anonymized GPS probes, a pipeline aggregates them into per-segment speeds, and a machine-learning model, in Google's case a Graph Neural Network over road Supersegments, predicts travel time and feeds those edge weights back into routing. Around all four sit place search, autocomplete, and reverse geocoding. The interview is really about picking the right spatial data structure and the right precomputation strategy for each piece.
Design Slack
Slack is a persistent-connection problem wearing a chat app's clothes. Every logged-in client holds a WebSocket to a gateway server, and the server pushes a stream of events for the channels that client cares about. On top of that live socket you layer a normal request/response web tier for sending messages, editing, and search, plus a durable store for message history. The design splits cleanly into three planes: a real-time delivery plane built on WebSockets and a gateway fleet, an application plane of stateless web servers that write to sharded MySQL through Vitess, and an edge caching plane called Flannel that keeps hot workspace metadata (users, channels, bots) close to clients so boot and reconnect stay cheap. The interview rewards candidates who separate ephemeral state (presence, typing) from durable state (messages, membership), who shard message storage by channel rather than by whole workspace to avoid hot shards, who compute per-user per-channel unread counts without scanning history, and who have a concrete answer for the reconnect storm when a gateway dies. Slack's real system uses Solr for message search, Envoy for terminating the socket fleet, and Enterprise Grid to stitch many workspaces into one organization.
Design Discord
Discord is two hard systems wearing one app. The first is a real-time gateway: every client holds a WebSocket, and events like new messages, typing, and presence must fan out to everyone watching a channel within a guild, sometimes millions of members. Discord models each guild as a single Elixir process on the BEAM that routes events to per-connection session processes, which works beautifully for small servers and becomes a fanout bottleneck for huge ones. The second system is durable message storage. Messages are immutable, append-heavy, and read by channel in reverse-chronological order, so Discord partitions them by channel and a time bucket and stores them in a wide-column store, first Cassandra and now ScyllaDB, fronted by a Rust data service that coalesces duplicate reads. On top of that sit voice servers running a homegrown selective forwarding unit over UDP and WebRTC, plus per-user read state, mentions, and unread counts. A strong answer treats fanout, storage partitioning, and voice as three separate scaling problems with three different solutions.
Design TikTok
The defining challenge of TikTok is the For You recommendation feed, not the video plumbing. A user opens the app with no explicit query and expects an endless stream of clips tuned to their taste, refreshed as their taste shifts inside a single session. The system answers this with a two-stage recommender. Candidate generation narrows hundreds of millions of videos down to a few hundred using cheap retrieval models and embedding lookups, then a heavier ranking model scores those candidates on many objectives at once, watch time, replay, like, share, comment, and follow probability. What makes the recommendations feel uncanny is freshness. ByteDance's Monolith training system updates the model online from live interaction streams rather than in nightly batches, so a signal from a video you watched a minute ago can influence what you see next. Around that core sits a conventional but very large video platform: an upload and transcoding pipeline that fans one master file into many bitrate and resolution renditions, object storage for the media, a CDN that pushes clips to edge caches near the viewer, and a client that aggressively prefetches the next few videos so the feed feels instant when you swipe.
Design Apache Kafka
Kafka is a distributed, partitioned, replicated commit log dressed up as a messaging system. A topic is split into partitions, and each partition is an append-only, totally ordered sequence of records addressed by a monotonically increasing offset. Producers append to the tail, consumers read forward at their own pace and track their own offset, and the same records can be re-read by many independent consumer groups because reading does not destroy the message. Ordering is guaranteed only within a partition, which is the price you pay for horizontal scale. Durability comes from replicating each partition to several brokers, with one leader taking all reads and writes and followers pulling to stay in sync. The in-sync replica set plus the acks setting lets you dial the tradeoff between latency and how many failures you can survive without losing an acknowledged write. The whole thing is fast because it leans on sequential disk I/O, the OS page cache, and zero-copy transfer rather than clever in-memory structures. Coordination that used to live in ZooKeeper now lives inside Kafka itself through the KRaft metadata quorum.
Design Amazon S3
Object storage exposes a dead simple contract: PUT an object under a key in a bucket, GET it back byte for byte, and never lose it. Underneath, that contract hides two genuinely hard systems. The first is the durability engine that takes each object, splits it into shards using Reed-Solomon erasure coding, and scatters those shards across many disks, racks, and availability zones so that no correlated failure can destroy more shards than the parity can rebuild, all while background scrubbers continuously read, verify checksums, and repair. The second is the metadata index that maps a key to the physical location of its shards, which must stay fast and consistent while holding entries for trillions of keys and absorbing request storms concentrated on a few hot prefixes. On top of those sit a stateless front-end router fleet, a chunked data path with multipart upload for large objects and range reads for partial GETs, and a lifecycle engine that migrates cold data into cheaper tiers. Since 2020 S3 has also offered strong read-after-write consistency, so a read that follows a successful write always sees the latest bytes. The design lesson is that availability comes from stateless replaceable front ends, and durability comes from spreading redundant coded data as widely as possible and never trusting a disk to tell you the truth about itself.
Design Databricks
Databricks is a lakehouse: one system that stores data in cheap open-format files on object storage, then layers warehouse guarantees on top so you get ACID transactions, schema, and fast SQL without copying data into a separate warehouse. The center of the design is Delta Lake, which turns a folder of Parquet files into a real table by keeping an ordered transaction log next to the data. Every write appends a JSON commit that lists which files were added and removed, so a reader reconstructs an exact table snapshot by replaying the log. Concurrency is handled optimistically: writers assume conflicts are rare, do their work, and only check for a collision at commit time. Storage and compute are fully separated, so elastic Spark clusters spin up against the same files and scale independently. Photon accelerates queries with vectorized C++ execution, data skipping prunes files using per-file statistics, and OPTIMIZE compacts small files. Unity Catalog sits above all of it for governance, permissions, and lineage. The medallion pattern, bronze to silver to gold, organizes raw ingestion through cleaned and aggregated tables.
Design Meta News Feed
The News Feed problem is the canonical feed-design interview. A user opens the app and expects a personalized, ranked list of recent posts from friends, groups, and pages, assembled in a few hundred milliseconds. The naive approach, query every friend's posts at read time and sort, does not survive contact with a user who follows thousands of accounts. The classic answer is fanout: precompute each user's feed on write (push) so reads are cheap, or assemble it on read (pull) so writes are cheap. Pure push breaks the moment a celebrity with tens of millions of followers posts, because one write becomes tens of millions of feed inserts. Real systems use a hybrid: push for ordinary authors, pull for high-fanout accounts, merged at read time. On top of retrieval sits ranking, which at Meta moved from reverse-chronological to a multi-pass machine-learned model that scores candidates with neural networks. Underneath sits the hard part most candidates skip: the storage and cache tier, Facebook's TAO graph store over sharded MySQL fronted by memcache, where cache invalidation and read consistency are where systems actually fall over.
Design Telegram
Telegram is a cloud-first messenger. Cloud chats live server-side, encrypted at rest but readable by Telegram, which is what lets a brand new phone log in and instantly see full history, search, and media. This is the deliberate split from WhatsApp, which keeps the source of truth on your phone. The account is pinned to a home data center chosen at registration, and all of that user's cloud data lives there. Clients hold a persistent MTProto session and receive updates in real time. When a client reconnects after being offline, it does not replay every event. It compares its local sequence counters (pts, qts, seq) against the server and calls getDifference or getChannelDifference to fetch only the delta. Groups scale to 200,000 members and broadcast channels are effectively unlimited, so the design has to handle both tight 1:1 delivery and massive one-to-many fanout. End-to-end encryption exists only in Secret Chats, which are bound to a single device pair and never touch the cloud.
Design Pinterest
Pinterest is a visual discovery engine. A pin is an image with a link and metadata, a board is a themed collection, and users save pins onto boards and follow other users and boards. The hard part is not storing pins, it is discovery: given a person or an image, find the most relevant pins out of billions in tens of milliseconds. The core data lives in heavily sharded MySQL where every object carries a 64-bit ID that encodes its shard, and all cross-object relationships are resolved with application-layer joins backed by memcache and Redis rather than SQL joins. On top of that sits a home feed built by a Smart Feed pipeline that generates candidates, scores them with a ranking model, and materializes a frozen view so the feed stays available even when a generator is slow. The recommendation core is graph-based: Pixie runs biased random walks over the pin-board graph in real time, and PinSage learns pin embeddings with a graph convolutional network so related pins can be retrieved by approximate nearest neighbor. Visual search adds a unified image embedding so a crop of an image maps to visually and semantically similar pins. Everything is read heavy, so caching and CDN image delivery matter as much as the models.
Design Airbnb
Airbnb is a two sided marketplace where hosts list homes and guests search, book, and pay. A guest types a place and a date range, and the system filters millions of listings by location, dates, price, guest count, and amenities, then ranks them with personalization, all in a couple hundred milliseconds. The genuinely hard subsystem is the booking write path: two guests can try to reserve the same listing for overlapping dates at the same instant, and the design must let exactly one of them win. That means a strongly consistent reservation store, usually a relational database sharded by listing, with row level locking or optimistic concurrency on the calendar, plus short lived holds during checkout. Search runs off a separate denormalized index such as Elasticsearch that is updated asynchronously from booking and calendar events, so search is eventually consistent by design while reservations are not. Payments split a guest charge from a delayed host payout and hold funds until after check in, which forces careful idempotency so a retried request never charges twice. The whole thing is a study in choosing where to pay for strong consistency and where eventual consistency is fine.
Design PayPal
PayPal is a consumer wallet, a peer-to-peer transfer network, and a checkout processor stacked on top of one money movement core. The center of the design is a double-entry ledger where every transaction writes balanced debit and credit entries that always sum to zero, and ledger rows are append-only so history can never be rewritten. Money movement demands strong consistency and ACID transactions rather than eventual consistency, because a lost or duplicated balance update is real money gone. Every write is made idempotent with a client-supplied request id so retries after a timeout do not move money twice. Flows that touch several services, for example debiting a wallet, running risk, and settling to a bank, are coordinated with sagas and compensating entries instead of a single global lock. Around the ledger sit real-time fraud and risk scoring in the authorization path, holds and authorization versus capture semantics, refunds, chargebacks and reversals, multi-currency balances with foreign exchange, and continuous reconciliation against banks and card networks. The interview is really about correctness under partial failure at high volume, not raw throughput.
Design Spotify
Spotify looks like a simple play button, but the interesting engineering sits underneath it. Audio is not generated on the fly the way video often is. Every track is pre-encoded into a handful of Ogg Vorbis bitrates, chunked, and pushed to a CDN so the client can start playback in a few hundred milliseconds and switch quality as the network changes. The catalog and metadata for tracks, albums, artists, and playlists need fast lookups and search across a huge corpus. Personalization is the other half of the product: collaborative filtering and content signals feed offline batch jobs that precompute recommendations like Discover Weekly, which are then served from low latency stores. Tying it all together is an event pipeline that captures every play, skip, and save. That pipeline feeds royalty accounting, analytics, and the recommendation models, so it has to be durable and ordered enough to trust with payments. The hard parts to talk about in an interview are audio delivery and caching, the recommendation pipeline that splits offline compute from online serving, and the event delivery backbone that Spotify famously moved from Kafka to Google Cloud Pub/Sub.
Design Snowflake
A cloud data warehouse has to serve fast analytical queries over enormous, mostly cold datasets while many teams load and read at once. Snowflake's answer is a three-layer split. Data sits once in object storage as immutable, compressed, columnar micro-partitions. Compute happens in virtual warehouses, which are elastic clusters you spin up, resize, and suspend independently, so an ingest job on one warehouse never fights a dashboard on another. A stateless cloud services layer holds all the brains: the optimizer, transaction manager, security, and the metadata catalog that records which micro-partitions make up each table version. Queries go fast not through indexes but through pruning, where per-column min and max statistics let the planner skip files that cannot match a predicate. Because files are immutable and tables are just a versioned list of files, you get ACID transactions with snapshot isolation, time travel to any point in a retention window, and zero-copy clones that duplicate a table by copying metadata rather than bytes. The design's core bet is that separating storage from compute buys near-infinite elasticity and workload isolation, and that object storage plus smart metadata can replace the tightly coupled shared-nothing clusters that came before.
Design Uber
Designing Uber means solving real-time location streaming, low-latency geospatial matching, and a strict trip state machine that survives driver disconnects, GPS gaps, and surge events. It is one of the most asked system design problems at FAANG and ride-hailing companies.
Design Netflix
Designing Netflix forces you to think about video encoding pipelines, multi-CDN delivery with adaptive bitrate, a recommendation system that drives 80% of watched content, and a microservices architecture that has to stay up while half a million users press play in the same minute.
Design WhatsApp
Designing WhatsApp forces you to combine real-time bidirectional messaging, durable offline delivery, end-to-end encryption, presence and typing indicators, and group fan-out. It is the canonical chat system design problem and a favorite at FAANG.
Design Twitter
Designing Twitter is the canonical timeline generation problem. You decide between push-based fan-out (precompute every follower's timeline) and pull-based aggregation (build on read), and the answer is almost always a hybrid that depends on follower count. It also touches search, ranking, and trending topics.
Design YouTube
Designing YouTube combines a giant video upload pipeline, multi-resolution encoding, CDN delivery, a massive recommendation system, and a comments and engagement layer. The hardest piece is the upload-to-playback pipeline: how a 4K video uploaded in Mumbai is playable in São Paulo within minutes.
Design Tiny URL Shortener
Designing a URL shortener (TinyURL, bit.ly) is the canonical warm-up system design interview. It looks simple but every detail matters: how you generate short IDs without collisions, how you shard a hot-read workload, how you cache, and how you do analytics without slowing down redirects.
Design Instagram
Designing Instagram combines photo upload pipelines, feed generation (similar to Twitter), Stories (a separate ephemeral feed), Direct Messages, and a heavy media CDN. The hardest piece is generating a personalized feed that mixes friends, followed accounts, and Reels recommendations in 200 milliseconds.
Design Stripe
Designing Stripe means designing a payment system from the API down to a double-entry ledger. The defining concerns are correctness (charge exactly once), durability (no charge is ever lost), regulatory compliance (PCI DSS scope, KYC), and global reach (multiple currencies and payment methods). It is the canonical system design problem where consistency dominates speed.
Design Amazon
Designing Amazon means designing an e-commerce stack from catalog and search through cart, checkout, inventory, payment, and fulfillment routing. It is one of the broadest system design problems because every step is a real subsystem with its own constraints. The hardest piece is keeping inventory consistent across 175 warehouses while serving sub-second search.
Design Dropbox
Designing Dropbox is really about two systems that pretend to be one. There is a metadata service that tracks files, folders, versions, and which chunks make up each file, and there is a block storage service that holds the actual bytes as content-addressed chunks. Files are split into fixed blocks of roughly 4 MB, each block is hashed, and identical blocks are stored once no matter how many users or files reference them. When a large file is edited, only the changed blocks are uploaded, which is called delta sync. A sync and notification service watches for changes and pushes them to every device that has the file, and conflict handling decides what happens when two offline devices edit the same file.
Design BookMyShow
A seat-level ticketing system where the hard part isn't scale, it's correctness under contention: 50,000 people clicking the same seat at the same millisecond, and exactly one of them must win. The design centers on a temporary seat-hold lock (Redis, ~10 min TTL, acquired with an atomic Lua compare-and-set), a virtual waiting room that gates the herd before it ever touches the booking service, and a payment saga that keeps the seat held until money clears, then either confirms the booking or releases the seat. Reads (seat maps, show listings) are massively cached and scale horizontally; writes (the actual booking) are funneled through a narrow, strongly-consistent path.
Design Delhivery
Designing Delhivery is the logistics-network problem, which is different from the consumer apps. A parcel is picked up, moves through a hub-and-spoke network of sort centers and gateways, and is delivered to a doorstep, and the whole thing runs at the scale of e-commerce infrastructure for the country. The distinctive engineering, and what Delhivery has published, is address intelligence: Indian addresses are unstructured and often carry the wrong pin code, so Delhivery built machine learning that resolves a messy address to a precise location, which lets it route by geocode rather than by pin code. This walkthrough covers the network, the address-resolution system Delhivery published, tracking at scale, and peak handling, and is honest about which internals are the standard logistics pattern.
Design Rapido
Designing Rapido is a ride-hailing problem with two things that make it distinct. First, the core vehicle is a two-wheeler, and Rapido has published how it matches riders to nearby bikes, moving from a simple radius-and-straight-line approach to hex-grid geography with learned driving times. Second, the money model is different: rather than taking a commission on each ride, Rapido charges captains a flat subscription and lets them keep the full fare, which changes the settlement path from a per-ride commission ledger to a subscription-entitlement check. This walkthrough covers the two-wheeler dispatch that Rapido has published, the subscription money model and its system implications, and the data platform behind it, and is honest about which parts are published versus reasoned.
Design Urban Company
Designing Urban Company is the services-marketplace problem, which is different from ride-hailing. There is no instant dispatch of the nearest driver. A customer books a service, cleaning, a salon appointment, a repair, into a future time slot, and the system has to decide which slots to even offer and which professional to send, based on skill, location, availability, and, crucially, the predicted chance that a professional will accept the job. Urban Company has published how it models this with machine learning, treating reliability, the chance a booking is actually fulfilled, as the thing to optimize. It also manages and trains its supply rather than using an open pool. This walkthrough centers on the scheduled matching and reliability modeling Urban Company published, and is honest about which pieces are the general marketplace pattern.
Design Google Docs
Google Docs lets many people edit the same document at the same time and each person sees the others' keystrokes almost instantly. The core problem is not storage, it is conflict resolution: two edits that happen concurrently must be merged so every client converges on the exact same final text. Google solves this with Operational Transformation, where each edit is a small operation that gets transformed against operations it did not know about. A single collaboration server per document gives every operation a total order, which is what makes convergence tractable. On top of that sit presence, remote cursors, offline editing with later reconciliation, comments, sharing permissions, and a version history built from the operation log.
Design Web Crawler
A web crawler starts from a set of seed URLs, fetches each page, extracts the links inside it, and enqueues the new URLs to fetch later. The hard part is not fetching one page, it is doing this across billions of pages while staying polite to each server, never crawling the same page twice, and keeping the crawled copy fresh. The heart of the design is the URL frontier, a large distributed queue that decides what to fetch next and enforces per-domain rate limits. Around it sit a DNS resolver with a cache, a pool of fetcher workers, a parser that extracts links and content, a dedup layer built from a URL bloom filter and content hashing, and a content store for the raw pages. Get the frontier and the politeness right and the rest of the system follows.
Design Search Autocomplete (Typeahead)
A typeahead system suggests the most likely completions for whatever prefix a user has typed so far, and it does this on every keystroke. The read path must be extremely fast because a suggestion has to come back before the user types the next character. The core trick is a trie (prefix tree) where each node stores the precomputed top-k completions for that prefix, so a lookup is O(length of the prefix) instead of a scan. Popularity comes from an offline pipeline that mines historical query logs and rebuilds the trie on a schedule. A separate fast path layers recent trends on top so spikes show up without waiting for the next full rebuild.