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 2 of 5
Ad Click Aggregator System Design Interview: Counting a Firehose Without Double-Charging Advertisers
An ad click aggregator ingests a massive stream of click and impression events, groups them into per ad, per time bucket counts, and serves two audiences from the same data: advertisers watching a near real time dashboard and a billing system that needs numbers it can defend. The core of the design is a durable log (Kafka) that absorbs the firehose and partitions events by ad id, a stream processor (Flink or Spark Structured Streaming) that runs windowed aggregation over event time, and an OLAP store (Druid, Pinot, or ClickHouse) that holds pre aggregated rollups and answers dashboard queries in well under a second. The hard parts are all about correctness under failure. Events arrive out of order and late, so you need watermarks and a grace period to decide when a minute is done. A click must be counted exactly once, so every event carries a stable id and gets deduplicated. A viral ad creates a hot partition that one consumer cannot keep up with. And because streaming counts can drift, most real systems keep a batch reconciliation path (or a replayable single stream) that produces the authoritative billing number a few hours later. The interview is really a tour of stream processing done under a billing constraint.
readAirbnb System Design Interview: Search, Availability, and the Race to Book the Same Listing
Airbnb is a two sided marketplace where hosts list homes and guests search, book, and pay. A guest types a place and a date range, and the system filters millions of listings by location, dates, price, guest count, and amenities, then ranks them with personalization, all in a couple hundred milliseconds. The genuinely hard subsystem is the booking write path: two guests can try to reserve the same listing for overlapping dates at the same instant, and the design must let exactly one of them win. That means a strongly consistent reservation store, usually a relational database sharded by listing, with row level locking or optimistic concurrency on the calendar, plus short lived holds during checkout. Search runs off a separate denormalized index such as Elasticsearch that is updated asynchronously from booking and calendar events, so search is eventually consistent by design while reservations are not. Payments split a guest charge from a delayed host payout and hold funds until after check in, which forces careful idempotency so a retried request never charges twice. The whole thing is a study in choosing where to pay for strong consistency and where eventual consistency is fine.
readAmazon S3 System Design Interview: Building Object Storage with Eleven Nines of Durability
Object storage exposes a dead simple contract: PUT an object under a key in a bucket, GET it back byte for byte, and never lose it. Underneath, that contract hides two genuinely hard systems. The first is the durability engine that takes each object, splits it into shards using Reed-Solomon erasure coding, and scatters those shards across many disks, racks, and availability zones so that no correlated failure can destroy more shards than the parity can rebuild, all while background scrubbers continuously read, verify checksums, and repair. The second is the metadata index that maps a key to the physical location of its shards, which must stay fast and consistent while holding entries for trillions of keys and absorbing request storms concentrated on a few hot prefixes. On top of those sit a stateless front-end router fleet, a chunked data path with multipart upload for large objects and range reads for partial GETs, and a lifecycle engine that migrates cold data into cheaper tiers. Since 2020 S3 has also offered strong read-after-write consistency, so a read that follows a successful write always sees the latest bytes. The design lesson is that availability comes from stateless replaceable front ends, and durability comes from spreading redundant coded data as widely as possible and never trusting a disk to tell you the truth about itself.
readApache Kafka System Design Interview: Building a Distributed Message Queue on a Commit Log
Kafka is a distributed, partitioned, replicated commit log dressed up as a messaging system. A topic is split into partitions, and each partition is an append-only, totally ordered sequence of records addressed by a monotonically increasing offset. Producers append to the tail, consumers read forward at their own pace and track their own offset, and the same records can be re-read by many independent consumer groups because reading does not destroy the message. Ordering is guaranteed only within a partition, which is the price you pay for horizontal scale. Durability comes from replicating each partition to several brokers, with one leader taking all reads and writes and followers pulling to stay in sync. The in-sync replica set plus the acks setting lets you dial the tradeoff between latency and how many failures you can survive without losing an acknowledged write. The whole thing is fast because it leans on sequential disk I/O, the OS page cache, and zero-copy transfer rather than clever in-memory structures. Coordination that used to live in ZooKeeper now lives inside Kafka itself through the KRaft metadata quorum.
readAPI 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 Netflix: System Design Interview Guide
Designing Netflix forces you to think about video encoding pipelines, multi-CDN delivery with adaptive bitrate, a recommendation system that drives 80% of watched content, and a microservices architecture that has to stay up while half a million users press play in the same minute.
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 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.
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.
read