Design a Web-Scale Search Engine
This is the first Hard problem in this module, and it's a genuine step up from the Medium tier for a specific reason: it isn't solved by picking one clever mechanism the way Design Twitter's fan-out choice was — it needs at least two independently hard sub-problems solved correctly at the same time (indexing the entire web, and ranking results fast enough for a human to feel like the answer was instant), plus the crawler from Design a Web Crawler feeding it continuously. Following the framework from How to Answer a System Design Interview Question.
Design YouTube (Video Streaming Platform)
Design Instagram already established the shape of this problem for images a single video needs to be transcoded into many different formats and qualities, and playback needs to adapt continuously to a viewer's changing network conditions rather than just loading once. Following the framework from How to Answer a System Design Interview Question.
Design a Distributed Message Queue (Kafka-like)
Every problem so far that needed asynchronous communication has treated Message Queues as a given piece of infrastructure to build on top of. This problem is the reverse: build the queue itself. It's a genuine step up in difficulty because a real message queue has to combine three things this course has so far treated mostly separately — ordered, durable storage; horizontal partitioning; and replication for fault tolerance — all in one system. Following the framework from How to Answer a System Design Interview Question.
Design a Global Ride-Sharing Dispatch System
Design Uber already solved the core matching problem — geohashing nearby drivers, locking one driver to one rider. This problem deliberately reuses that solution rather than re-deriving it, and asks a different, harder question on top: what changes when the same service has to run simultaneously across dozens of countries and continents, survive an entire region going dark, and still present riders and drivers with one coherent global product? Following the framework from How to Answer a System Design Interview Question.
Design a Payments System (Stripe-like)
Design an E-commerce Checkout System covered using a payment provider — reserving inventory, calling out to charge a card, handling the response. This problem is building the payment provider itself: the system of record for where money actually is, that has to stay correct even when the bank or card network on the other end of a call gives an ambiguous or delayed answer. Following the framework from How to Answer a System Design Interview Question.
Design a Distributed Cache (Redis-like)
Design a Key-Value Store built a Dynamo-style store where losing data is unacceptable. This problem looks similar on the surface — the same GET/SET shape, the same need to partition across nodes — but starts from the opposite non-functional requirement: this store is a cache, sitting in front of another system that's already the source of truth, so losing its data is an acceptable, recoverable event, and that one difference changes almost every decision that follows. It's the system Distributed Caching already describes conceptually; this problem builds it. Following the framework from How to Answer a System Design Interview Question.