Blog
System design, written down properly
Walkthroughs, interview problems and engineering notes. Every post is built from something that was actually measured or built, not summarised from elsewhere.
Roni Das
Founder, SystemDesign Academy
77 posts · page 3 of 4
- Interview
IRCTC System Design Interview: Tatkal and Train Booking at Scale
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.
Read - Interview
JioHotstar (Hotstar) System Design Interview: 65M Viewers
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.
Read - Interview
Leaderboard System Design Interview: Real-Time Ranking at Scale
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.
Read - Interview
Meesho System Design Interview: Discovery Commerce at Scale
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.
Read - Interview
Meta (Facebook) News Feed System Design Interview: Fanout, Feed Ranking, and the Celebrity Problem
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.
Read - Interview
Notification System Design Interview: Multi-Channel Delivery, Fanout, and Idempotency at Scale
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.
Read - Interview
Nykaa System Design Interview: Omnichannel Beauty Commerce
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.
Read - Interview
Ola System Design Interview: Ride-Hailing and Maps at Scale
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.
Read - Interview
Online Judge System Design Interview: Running Untrusted Code Safely at Contest Scale
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.
Read - Interview
PayPal System Design Interview: Moving Money Exactly Once Without Ever Losing a Cent
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.
Read - Interview
Paytm System Design Interview: UPI, Ledgers, Idempotency
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.
Read - Interview
PhonePe System Design Interview: UPI at National Scale
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.
Read - Interview
Pinterest System Design Interview: Visual Discovery, the Pin-Board Graph, and Recommendations at Scale
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.
Read - Interview
Rapido System Design Interview: Bike-Taxi Dispatch at Scale
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.
Read - Interview
Rate Limiter System Design Interview: Counting Requests Correctly Across a Fleet
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.
Read - Interview
Recommendation System Design Interview: Two-Stage Candidate Generation and Ranking at Billion-Item Scale
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.
Read - Interview
Reddit System Design Interview: Comment Trees, Vote Ranking, and Cached Listings at Scale
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.
Read - Interview
Redis System Design Interview: Building a Single-Threaded In-Memory Data Store That Serves Millions of Ops per Second
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.
Read - Interview
Search Autocomplete (Typeahead) System Design Interview
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.
Read - Interview
Slack System Design Interview: Real-Time Messaging for Millions of Persistent Connections
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.
Read