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
Lessons and tutorials at systemdesign.academy
106 posts · page 4 of 6
Flipkart System Design: Big Billion Days Flash Sales
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.
readGoogle Docs System Design Interview: Real-Time Collaborative Editing
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.
readGoogle Drive System Design Interview: Syncing Billions of Files Without Re-Uploading Them
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.
readGoogle Maps System Design Interview: Geospatial Indexing, Tile Serving, and Continent-Scale Routing
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.
readGoogle Search System Design Interview: Serving a Trillion-Page Inverted Index in 200 Milliseconds
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.
readGroww System Design Interview: Mass-Market Investing at Scale
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.
readIRCTC 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.
readJioHotstar (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.
readLeaderboard 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.
readMeesho 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.
readMeta (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.
readNetflix System Design: How Playback, Open Connect and Encoding Work
Designing Netflix is two designs that meet at the play button. The control plane runs in AWS. It handles sign-in, the home page, what to play and which server should send it. The data plane is Open Connect, Netflix's own content delivery network. Its servers sit inside internet providers and only store and send video files. Most of the interview is about the line between those two planes. It is also about the work done before anyone presses play. Every title is encoded into many versions, and files are copied to the right servers overnight.
readNotification 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.
readNykaa 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.
readOla System Design: Ola Maps, Live Tracking and Matching
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.
readOnline 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.
readPayPal 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.
readPaytm 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.
readPhonePe 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.
readPinterest 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