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 3 of 6
API Gateway System Design Interview: Building the Single Front Door for Hundreds of Microservices
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.
readBookMyShow System Design: Seat Booking Concurrency
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.
readCode Deployment System Design Interview: Shipping a Commit to 100,000 Servers Safely
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.
readCRED System Design Interview: Bill Payments and Rewards at Scale
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.
readDatabricks System Design Interview: Building a Lakehouse with ACID on Object Storage
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.
readDelhivery System Design Interview: Logistics Network at Scale
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 sort by resolved locality rather than by the written 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.
readDesign Amazon: System Design Interview Guide
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.
readDesign Instagram: System Design Interview Guide
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.
readDesign 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.
readDesign 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.
readDesign 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.
readDesign 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.
readDesign 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.
readDesign 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.
readDigital 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.
read