System Design Tutorials

System design from the parts list to the whiteboard — estimation, load balancing, caching, database scaling, consistency, queues, concurrency and rate limiting, then full walkthroughs of Airbnb, Amazon, an airline booking system, YouTube, a URL shortener, chat and notifications. Every mechanism is shown working in a real booking application rather than described, and every number quoted was measured on the machine that wrote it.

• System Design Interview Questions
  The questions you need to be able to answer, with answers that are short enough to say out loud. Fundamentals, scaling, data, distributed systems and the case-study openers — each answered in a few sentences, each linked to the post that works it through properly, and each followed by the follow-up an interviewer actually asks next.
• Designing YouTube
  The first case study here that is not a transactional system: nobody contends for a video, and the difficulty is bytes. Resumable uploads, transcoding as a fan-out of keyed tasks, and the cache split that makes a 99% edge hit rate reachable — then advertising as part of the playback path, server-side against client-side insertion, impression billing that has to be exactly once, and the recommendation and campaign machinery that gets a video watched.
• Designing an Airline Booking System
  Flight booking, which is the seat-hold problem from the concurrency post at a much harder scale. Searching a graph of routes rather than a list of rows, fare classes and the inventory buckets that make pricing possible, holding a seat while payment completes, deliberate overbooking as a business rule, PNRs and ticketing, integration with systems older than the web, and what happens when a storm cancels four hundred flights at once.
• Designing Amazon
  An e-commerce system at the scale where every easy answer stops working. Catalog modelling for wildly different product types, search and faceting, the cart that must survive a logout, inventory reservation and oversell, the order state machine and why payment is a saga rather than a transaction, fulfilment across warehouses, and recommendations that are computed offline rather than at request time.
• Designing Airbnb
  The full walkthrough, and the one case study where every claim is backed by a running application. Requirements and estimates, the API and the schema, search over a denormalised index, availability and the booking race, pricing as a security boundary, payments and the webhook that is the real source of truth, cancellation policy, then how each piece changes when the traffic multiplies.
• Designing a Notification System
  One system, three channels, and every hard part in the delivery guarantees. Provider abstraction so a failing vendor is a config change, fan-out that survives a burst, retries and deduplication when delivery is at-least-once, the preference and opt-out rules that are a legal requirement rather than a feature, rate control so a bug cannot send ten thousand emails, and the templating that keeps copy out of code.
• Designing a Customer Data Platform
  CRM, Billing and Support each think they own the customer, they disagree, and they arrive out of order. The design that produces one profile and can still explain why it chose every value — field-level observations, a pure survivorship function, identity resolution with reversible merges, and a lineage endpoint that shows what lost.
• Designing a Chat System
  Real-time messaging end to end. Polling, long polling, server-sent events and WebSockets — what each costs and when each is right; the connection registry that lets one server find a user connected to another; message ordering when clocks disagree; storage that supports "load older messages" cheaply; group chat fan-out and the point at which it stops working; presence, delivery receipts and offline delivery.
• Designing a URL Shortener
  The classic warm-up question, worked properly. Requirements and estimates, base62 encoding against hash-and-truncate, how to handle collisions without a retry loop that never terminates, the 301-versus-302 decision that also decides whether you get analytics, the read path and its cache, custom aliases, and expiry that does not require scanning the table.
• Designing a Unique ID Generator
  Four ways to mint an id at scale and the single tradeoff that decides between them: sortability against coordination. Database auto-increment, UUIDv4 and v7, a ticket server, and Snowflake — with the bit layout worked through, the clock-skew failure everyone forgets, and why a system can want two ids for the same row rather than one.
• Rate Limiting
  Four algorithms and what each one does at the boundary: fixed window and its doubling bug, sliding log, sliding window counter, and the token bucket that wins most of the time. Where the limiter belongs, how to identify a caller without handing them a way to reset their own quota, why the counter must be atomic, and the 429 contract a client can actually back off against.
• Concurrency – Double Booking and Distributed Locks
  Two guests, one room, the same millisecond. Why the check-then-write everyone writes first is always wrong, optimistic against pessimistic locking, the database constraints that make a race impossible rather than unlikely, idempotency keys for requests that must not run twice, and distributed locks — what they cost, how they fail, and why they belong last on the list rather than first.
• Message Queues and Asynchronous Work
  Why the line after a commit is the most dangerous line in the file, and what to do about it. Queues against logs, at-least-once delivery and the idempotency it forces, the transactional outbox, retries with exponential backoff, dead-letter queues, and how a worker claims work without two workers doing it twice. Every piece taken from a queue that runs, including the duplicate it produced.
• Consistency, Availability and CAP
  CAP without the folklore — what the theorem says, what it does not say, and why PACELC is the more useful version day to day. Strong against eventual consistency, read-your-writes and monotonic reads, quorums, and the dual-write problem that appears the moment a second datastore enters the design. Shown against a live Postgres-to-Elasticsearch sink, including exactly where it goes wrong.
• Scaling the Database
  The order to do things in, because most systems reach for sharding several steps too early. Indexes and query plans, connection pooling, read replicas and the replica lag that breaks read-your-writes, vertical against horizontal, partitioning versus sharding, choosing a shard key you will not regret, hot shards, and what resharding actually costs once you are live.
• Caching – Patterns, Invalidation and What Breaks
  A cache-aside read on a real endpoint, measured cold and warm, then everything that makes caching hard rather than easy. Write-through against write-behind, TTL and eviction policies, the two invalidation strategies and why you want both, cache stampede and how to stop it, and the rule that decides whether a cache is an optimisation or a new single point of failure.
• Load Balancing and the Stateless Tier
  Getting a request to a server that can answer it — and, better, not sending it at all. Layer 4 versus layer 7, round robin against least connections, health checks that actually detect a sick instance, and why sticky sessions are a trap rather than a feature. What "stateless" really requires of your application, how a JWT delivers it, and where a CDN removes the request entirely.
• Back-of-the-Envelope Estimation
  The step most candidates skip and most interviewers weight heavily. Powers of two and the latency numbers worth memorising, then the arithmetic that turns "design Airbnb" into concrete QPS, storage and bandwidth figures — worked end to end from real row counts. How to size a cache, when a number tells you the design is wrong, and why being an order of magnitude out is fine but a thousand times out is not.
• System Design Basics – The Parts of a Production System
  Every box on the whiteboard, named and justified: DNS, CDN, load balancer, a stateless web tier, cache, primary and replica databases, a message queue, object storage, and the logging and metrics that tell you which one is broken. Built up from a single server to a system that survives real traffic, with the reason each part gets added at the point it stops being optional — plus where a monolith is still the right answer.
• System Design – Where to Start
  What system design actually is, why the question has no single right answer, and the four-step framework that keeps an hour from wandering: scope the requirements, estimate the load, sketch a high-level design, then go deep on the part that matters. What an interviewer is really scoring, the mistakes that sink candidates who know the material, and how the rest of this track is ordered.