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 2 of 4
- Interview
Design Razorpay UPI Payment System: Interview Guide
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.
Read - Interview
Design Stripe: System Design Interview Guide
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.
Read - Interview
Design Twitter: System Design Interview Guide
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.
Read - Interview
Design Uber: System Design Interview Guide
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.
Read - Interview
Design URL Shortener: System Design Interview Guide
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.
Read - Interview
Design WhatsApp: System Design Interview Guide
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.
Read - Interview
Design YouTube: System Design Interview Guide
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.
Read - Interview
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.
Read - Interview
Discord 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.
Read - Interview
Distributed Counter System Design Interview: Counting Likes and Views Without a Hot Shard
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.
Read - Interview
Distributed 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.
Read - Interview
Dream11 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.
Read - Interview
Dropbox System Design Interview: File Storage and Sync at Scale
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.
Read - Interview
Elasticsearch 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.
Read - Interview
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.
Read - Interview
Google 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.
Read - Interview
Google 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.
Read - Interview
Google 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.
Read - Interview
Google 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.
Read - Interview
Groww 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.
Read