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
90 posts · page 3 of 5
Digital Wallet System Design Interview: The Double-Entry Ledger Behind Every Balance
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.
readDiscord System Design Interview: Real-Time Chat and Voice at Guild Scale
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.
readDistributed Job Scheduler System Design Interview: Firing Millions of Cron and One-Off Jobs on Time Without Duplicates
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.
readDream11 System Design Interview: Fantasy Sports at Scale
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.
readDropbox System Design: Sync, Dedup and Magic Pocket
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.
readElasticsearch System Design Interview: Building a Distributed Full-Text Search Engine
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.
readFlipkart 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.
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.
read