System Design Capstone Projects
Knowing what a load balancer does is one thing. Walking into a room and designing WhatsApp from a blank whiteboard in 45 minutes is another. The capstone projects are where every concept you have learned stops being a definition and becomes a decision. You take requirements, do the math on scale, choose a data model, draw the architecture, and then defend your choices when someone asks "what happens when this region goes down?"
These twenty projects are the systems interviewers actually ask about and the systems real companies actually run. Each one forces a different set of trade-offs: a URL shortener is mostly about read scale and key generation, a payment system is about correctness and idempotency, a chat app is about delivery guarantees and presence. Work through all of them and you stop pattern-matching to memorized answers. You start reasoning from first principles, which is exactly what separates a candidate who passes from one who gets the offer.
What a capstone project actually is
A capstone is a full design exercise for one named system, built the way a senior engineer would build it under time pressure. It is not a feature list. It starts by pinning down what the system must do, then estimates how big it has to be, then turns those numbers into concrete component choices.
Every project in this set follows the same backbone. First, clarify functional requirements (what the user can do) and non-functional ones (how fast, how available, how consistent). Second, do back-of-the-envelope math: daily active users, requests per second, storage growth per year, read-to-write ratio. Those numbers drive everything that follows. Third, sketch the high-level architecture: clients, API layer, services, data stores, caches, queues. Fourth, go deep on the one or two parts that are genuinely hard for this particular system.
That last step is the point. Designing a Rate Limiter is interesting because of the counter algorithm and where you store it. Designing a Notification System is interesting because of fan-out and delivery retries. The skill is knowing which part deserves your forty minutes and which part is boilerplate you can describe in one sentence.
The projects and what each one teaches
The twenty projects are deliberately spread across problem types so you cover the full range of design pressures.
Read-heavy and cache-first: Design a URL Shortener, Design a Content Delivery Network, and Design Google Search all push you to think about caching layers, key generation, and serving billions of reads cheaply. Write-heavy and fan-out: Design Twitter/X Feed, Design a Notification System, and Design a Chat System like WhatsApp center on the fan-out problem, message ordering, and delivery guarantees.
Correctness-critical: Design a Payment System and Design an E-Commerce Platform are about idempotency, exactly-once semantics, and not losing money when a request retries. Storage and replication: Design a Key-Value Store, Design a File Storage System like Dropbox, and Design YouTube/Netflix dig into partitioning, replication, and moving large blobs. Real-time and geospatial: Design Uber/Ride Sharing, Design a Real-Time Analytics Dashboard, and Design a Metrics/Monitoring System cover streaming ingestion, time-series storage, and location indexing.
The infrastructure and modern set rounds it out: Design an API Gateway, Design a Distributed Task Scheduler, and Design a Multi-Region Deployment are the plumbing senior interviews probe. Design a RAG System at Scale and Design an AI Agent Platform are the newer questions that almost no other course covers yet, and they are showing up in interviews now.
Choosing the right approach and owning the trade-offs
There is no single correct design for any of these, and saying so out loud is part of doing it well. The interviewer is testing whether you understand consequences, not whether you memorized one blessed diagram.
Take the feed problem in Design Twitter/X Feed. Fan-out on write (push a post into every follower's timeline at post time) makes reads instant but explodes when a celebrity with fifty million followers posts. Fan-out on read (build the timeline when the user opens the app) keeps writes cheap but makes reads slow and heavy. The real answer is hybrid: push for normal users, pull for celebrities. You only get to that answer by stating both options and their breaking points.
The same shape repeats everywhere. In Design a Rate Limiter you weigh a fixed window (simple, but allows bursts at boundaries) against a sliding window or token bucket (smoother, more state). In Design a Payment System you trade strong consistency and latency for correctness, because a double charge is worse than a slow charge. In Design a Multi-Region Deployment you confront the consistency-versus-availability choice head on: active-active gives low latency everywhere but forces you to resolve conflicts, while active-passive is simpler but wastes a region and adds failover lag. Naming the trade-off and explaining when each side wins is the entire skill.
How real companies build these systems
These are not toy problems. Every project maps to production systems running at companies you know, and grounding your design in how they actually did it makes your answer credible.
Design a Chat System like WhatsApp mirrors how WhatsApp served hundreds of millions of users with a famously small engineering team using long-lived connections and message queues. Design YouTube/Netflix follows the playbook of pre-encoding video into many bitrates and pushing it to edge servers, exactly what Netflix Open Connect does inside ISP networks. Design Uber/Ride Sharing reflects how Uber indexes the world with geospatial sharding to match riders and drivers in real time.
The newer projects matter just as much. Design a RAG System at Scale and Design an AI Agent Platform reflect the architectures that companies are shipping right now to put language models into production: vector stores, retrieval pipelines, tool orchestration, and the cost and latency controls that keep them affordable. Because these questions are new, strong answers stand out immediately. When you can explain not just the textbook design but the version that real teams ship, with the compromises they accepted, you are no longer reciting an answer. You are thinking like the engineer they want to hire.