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 4 of 4
- Interview
Snowflake System Design Interview: Building a Cloud Data Warehouse That Separates Storage from Compute
A cloud data warehouse has to serve fast analytical queries over enormous, mostly cold datasets while many teams load and read at once. Snowflake's answer is a three-layer split. Data sits once in object storage as immutable, compressed, columnar micro-partitions. Compute happens in virtual warehouses, which are elastic clusters you spin up, resize, and suspend independently, so an ingest job on one warehouse never fights a dashboard on another. A stateless cloud services layer holds all the brains: the optimizer, transaction manager, security, and the metadata catalog that records which micro-partitions make up each table version. Queries go fast not through indexes but through pruning, where per-column min and max statistics let the planner skip files that cannot match a predicate. Because files are immutable and tables are just a versioned list of files, you get ACID transactions with snapshot isolation, time travel to any point in a retention window, and zero-copy clones that duplicate a table by copying metadata rather than bytes. The design's core bet is that separating storage from compute buys near-infinite elasticity and workload isolation, and that object storage plus smart metadata can replace the tightly coupled shared-nothing clusters that came before.
Read - Interview
Spotify System Design Interview: Streaming Audio, Discover Weekly, and Billions of Play Events
Spotify looks like a simple play button, but the interesting engineering sits underneath it. Audio is not generated on the fly the way video often is. Every track is pre-encoded into a handful of Ogg Vorbis bitrates, chunked, and pushed to a CDN so the client can start playback in a few hundred milliseconds and switch quality as the network changes. The catalog and metadata for tracks, albums, artists, and playlists need fast lookups and search across a huge corpus. Personalization is the other half of the product: collaborative filtering and content signals feed offline batch jobs that precompute recommendations like Discover Weekly, which are then served from low latency stores. Tying it all together is an event pipeline that captures every play, skip, and save. That pipeline feeds royalty accounting, analytics, and the recommendation models, so it has to be durable and ordered enough to trust with payments. The hard parts to talk about in an interview are audio delivery and caching, the recommendation pipeline that splits offline compute from online serving, and the event delivery backbone that Spotify famously moved from Kafka to Google Cloud Pub/Sub.
Read - Interview
Stock Exchange System Design Interview: Building a Microsecond Order Matching Engine
A stock exchange is a low-latency deterministic matching system, not a CRUD app. Orders arrive over gateways, get validated and risk-checked, then flow into a single sequenced input stream that assigns each event a monotonic sequence number. A single-threaded matching engine consumes that stream and applies each order to an in-memory limit order book, which keeps resting orders sorted by price and, within a price level, by arrival time. Matching follows price-time priority: the best price trades first, and ties break by who got there earliest. Because every replica consumes the exact same ordered input and the engine is deterministic, all replicas compute byte-identical output, so recovery and hot standby become replay problems rather than distributed-consensus problems on the hot path. Durability comes from journaling the sequenced input to an append-only log before or in parallel with matching, in the style of the LMAX Disruptor. Fills and book changes fan out as a market data feed with periodic snapshots plus incremental deltas. The design goal is microsecond-scale, jitter-free matching with zero data loss and provable determinism.
Read - Interview
Swiggy System Design Interview: Live Order Tracking
Designing Swiggy means solving three coupled problems at once: serviceability (which restaurants can even reach this customer), dispatch (which delivery partner picks up which order, often batched), and a three-party order state machine that survives a restaurant rejecting an order, a partner going offline mid-trip, or a payment webhook arriving late. The hard part is that almost all of the load lands in two short meal peaks, so the system is sized for 4-5x its average and idle the rest of the day.
Read - Interview
Telegram System Design Interview: Cloud Messaging, Multi-Device Sync, and Million-Subscriber Channels
Telegram is a cloud-first messenger. Cloud chats live server-side, encrypted at rest but readable by Telegram, which is what lets a brand new phone log in and instantly see full history, search, and media. This is the deliberate split from WhatsApp, which keeps the source of truth on your phone. The account is pinned to a home data center chosen at registration, and all of that user's cloud data lives there. Clients hold a persistent MTProto session and receive updates in real time. When a client reconnects after being offline, it does not replay every event. It compares its local sequence counters (pts, qts, seq) against the server and calls getDifference or getChannelDifference to fetch only the delta. Groups scale to 200,000 members and broadcast channels are effectively unlimited, so the design has to handle both tight 1:1 delivery and massive one-to-many fanout. End-to-end encryption exists only in Secret Chats, which are bound to a single device pair and never touch the cloud.
Read - Interview
Ticketmaster System Design Interview: Selling Scarce Seats Without Double-Booking
A ticketing platform looks simple until one hot event goes on sale and a hundred thousand people fight over forty thousand seats in the same sixty seconds. The core requirement is that a given seat is sold to exactly one buyer, ever, even under massive concurrency, while the site stays up for everyone else. The design has three load-bearing pieces. First, a virtual waiting room that holds and paces arrivals so the booking backend only ever sees traffic it can handle. Second, a reservation model where selecting a seat places a short temporary hold that auto-releases if payment does not complete, so abandoned carts do not lock inventory forever. Third, an idempotent, serialized commit path where the transition from held to sold happens under a lock or a conditional write that a competing request cannot win twice. Around that sit the seat map, the payment integration, and a reconciliation loop that cleans up expired holds. Get the waiting room, the hold expiry, and the atomic sell right, and the rest is standard web engineering.
Read - Interview
TikTok System Design Interview: The For You Feed and Its Real-Time Recommender
The defining challenge of TikTok is the For You recommendation feed, not the video plumbing. A user opens the app with no explicit query and expects an endless stream of clips tuned to their taste, refreshed as their taste shifts inside a single session. The system answers this with a two-stage recommender. Candidate generation narrows hundreds of millions of videos down to a few hundred using cheap retrieval models and embedding lookups, then a heavier ranking model scores those candidates on many objectives at once, watch time, replay, like, share, comment, and follow probability. What makes the recommendations feel uncanny is freshness. ByteDance's Monolith training system updates the model online from live interaction streams rather than in nightly batches, so a signal from a video you watched a minute ago can influence what you see next. Around that core sits a conventional but very large video platform: an upload and transcoding pipeline that fans one master file into many bitrate and resolution renditions, object storage for the media, a CDN that pushes clips to edge caches near the viewer, and a client that aggressively prefetches the next few videos so the feed feels instant when you swipe.
Read - Interview
Tinder System Design Interview: Geosharded Recommendations and the Billion-Swipe Match Problem
Tinder is a location-based dating app where each user is shown a deck of nearby candidate profiles, swipes right (like) or left (pass) on each, and a mutual right swipe creates a match that opens a chat. The design has three genuinely hard subsystems. First, recommendation retrieval: given a user's location and distance filter, return candidates ranked by relevance, which Tinder solves with geosharding using Google's S2 library so a query touches only a handful of shards instead of a global index. Second, the swipe pipeline: billions of swipes per day are ingested as an ordered stream, left swipes are archived cheaply while right swipes are checked against a likes store to detect the reciprocal like. Third, match detection has to be idempotent and race-free so a simultaneous double right swipe produces exactly one match. Around these sit profile and photo storage on object storage plus a CDN, a match and chat service backed by a durable message store with real-time delivery over persistent connections, and push notifications. The recurring themes are geo-partitioning, write-heavy stream processing, and cache-backed reciprocal lookups.
Read - Interview
Twitch System Design Interview: Live Video Ingest, Transcode, and Chat at Scale
Twitch is a live video platform, which makes it a very different design problem from Netflix or YouTube VOD. A broadcaster pushes one live RTMP stream, and Twitch has to accept it at a nearby point of presence, route it to an origin, transcode it into multiple renditions in real time, package it as HLS segments, and push those segments through a CDN to potentially millions of viewers, all while keeping glass-to-glass latency in the low single digit seconds. On top of that sits a real-time chat system that has to deliver a firehose of messages per channel with strict ordering and moderation. The hardest parts are the transcode fleet economics, the thundering herd when a huge streamer goes live and every viewer requests the first segment at once, keeping live latency low without breaking CDN cacheability, and building a chat fanout tier that can hold tens of millions of persistent connections. Twitch built custom systems for most of this, including Intelligest for ingest routing and a purpose built transcoder, and a Go based chat edge and pubsub layer. A good interview answer separates the video plane from the chat plane and treats them as two independent scaling problems that happen to share a channel identity.
Read - Interview
Uber Eats System Design Interview: Dispatching Couriers and Predicting ETAs on a Three-Sided Marketplace
Uber Eats is a three-sided real-time marketplace. Eaters open the app at a delivery address and expect a ranked list of nearby restaurants that can actually deliver to them quickly, which makes search fundamentally geospatial rather than purely lexical. When an order is placed, the platform runs a distributed transaction across payments, the restaurant point-of-sale, and courier dispatch, then keeps everyone updated with a live map. The hardest parts are dispatch and timing: the system has to predict how long the food will take to cook, when a courier will reach the restaurant, and how long the final leg to the eater will take, then solve a global assignment problem that pairs orders with couriers to minimize total wait and keep food hot. On top of that sit geo-sharded search indexes, streaming location pipelines, surge pricing during demand spikes, and a payment split that pays the restaurant, the courier, and captures Uber's fee. A good design separates the read-heavy discovery path from the write-heavy order and dispatch path, and treats ETA prediction as a first-class machine learning system rather than a fixed constant.
Read - Interview
Urban Company System Design Interview: Services Marketplace at Scale
Designing Urban Company is the services-marketplace problem, which is different from ride-hailing. There is no instant dispatch of the nearest driver. A customer books a service, cleaning, a salon appointment, a repair, into a future time slot, and the system has to decide which slots to even offer and which professional to send, based on skill, location, availability, and, crucially, the predicted chance that a professional will accept the job. Urban Company has published how it models this with machine learning, treating reliability, the chance a booking is actually fulfilled, as the thing to optimize. It also manages and trains its supply rather than using an open pool. This walkthrough centers on the scheduled matching and reliability modeling Urban Company published, and is honest about which pieces are the general marketplace pattern.
Read - Interview
Web Crawler System Design Interview: Crawling the Web at Scale
A web crawler starts from a set of seed URLs, fetches each page, extracts the links inside it, and enqueues the new URLs to fetch later. The hard part is not fetching one page, it is doing this across billions of pages while staying polite to each server, never crawling the same page twice, and keeping the crawled copy fresh. The heart of the design is the URL frontier, a large distributed queue that decides what to fetch next and enforces per-domain rate limits. Around it sit a DNS resolver with a cache, a pool of fetcher workers, a parser that extracts links and content, a dedup layer built from a URL bloom filter and content hashing, and a content store for the raw pages. Get the frontier and the politeness right and the rest of the system follows.
Read - Interview
Yelp System Design Interview: Nearby Business Search at Scale
Yelp is a local discovery product, so the interview is really about geospatial search over a mostly static, read-heavy dataset. You have businesses with a location, categories, hours, price, and a stream of user reviews that roll up into a rating. A query carries a point or a map bounding box plus filters, and you must return the most relevant businesses ranked by a blend of distance, rating, and text match. The core design problem is the spatial index: a plain latitude and longitude B-tree cannot answer 'within N km' efficiently, so you reduce 2D proximity to a 1D or hierarchical key using geohash, a quadtree, or Google S2 cells, and let a search engine like Elasticsearch or Lucene do the filtering and scoring. Ranking is a two-phase retrieve-then-rank pipeline: the search engine recalls a candidate pool cheaply, then a learning-to-rank model reorders it. Everything sits behind read replicas and aggressive caching because the same popular queries and neighborhoods repeat constantly. Writes (new reviews, rating recomputation, business edits) go through a separate path and are indexed near real time.
Read - Interview
Zepto System Design Interview: 10-Minute Delivery at Scale
Designing Zepto is the quick-commerce problem, which is different from food delivery. Zepto does not pick from restaurants or third-party shops; it stocks its own small warehouses, called dark stores, placed close to customers, and delivers in about 10 minutes. That promise drives everything: dense stores, a small curated set of high-demand products, in-store picking in under 75 seconds, and real-time inventory per store so it never sells what a specific store does not have. This walkthrough centers on the dark-store model and the data architecture Zepto has published, including a purpose-built order pipeline that splits fast draft orders from durable confirmed orders, and is honest that the store-placement and dispatch details are the general quick-commerce pattern.
Read - Interview
Zerodha System Design Interview: Real-Time Trading at Scale
Designing Zerodha is the real-time trading problem. You have to stream live market prices to hundreds of thousands of users at once with very low latency, take an order from a phone and route it to the exchange and back through an order management system, keep positions and funds correct to the paisa, and survive the enormous spike at the 9:15 market open. It is also a lesson in restraint: Zerodha runs this at national scale on a small team with few services, a Postgres-first design, and Redis holding the hot data in memory. The interview rewards both the real-time streaming design and the judgment to keep the system simple.
Read - Interview
Zomato System Design Interview: Food Delivery at Scale
Designing Zomato is the hyperlocal food delivery problem at India scale. You have to decide which restaurants can actually reach an address in milliseconds, place and track an order through a state machine shared by the customer, the restaurant and the delivery partner, assign and batch delivery partners efficiently, and predict a delivery time the customer can trust while the kitchen, the traffic and even the weather keep changing. The constraint that shapes everything is that most of a day's two million orders arrive in two short meal windows, so the system has to be built for a spike that is many times its daily average.
Read - Interview
Zoom System Design Interview: Routing Live Video to Millions With an SFU
Zoom is a real-time video conferencing system, and the whole design turns on one decision: how do you get every participant's camera and microphone to everyone else in a meeting without melting a server or a laptop. A full mesh where each client sends directly to every other client scales as N squared and dies past a handful of people. An MCU that decodes, mixes, and re-encodes one combined stream per participant is CPU-brutal and adds latency. Zoom, like most modern systems, uses a Selective Forwarding Unit: each client uploads one stream, the media router forwards the right copies down to each receiver, and no decoding or mixing happens on the server. Clients help by sending simulcast, meaning several quality layers of the same camera at once, so the router can hand a weak connection a low bitrate copy and a strong one the full resolution. Media rides UDP because a late packet is worse than a lost one, and the app leans on jitter buffers, forward error correction, and adaptive bitrate to survive real networks. Signaling, region selection to the nearest data center, large-meeting fanout, and cloud recording all sit around that media core.
Read