Every one of these apps reduces to the same 7 building blocks: two ways to do the work, five ways to store it, plus three outside forces (users, other services, time) that decide which ones you need. Watch Kay Ashaolu, a UC Berkeley lecturer, apply that same toolkit to 15 different problems, from a blog to a live auction, and explain the design decisions instead of just showing the finished diagram.
15 case studies9:52 to 26:35 eachFree to watch, course to build
The whole series starts with the smallest system that can still handle real traffic: one Service, one Relational Database, and nothing else. Everything after this section adds a building block only when a specific new force demands it.
Start here
Link Shortener Service9:52Case Study 15
Designing a Link Shortener: The Simplest System That Scales
Io, a junior engineer, wants to build a link shortener for colleagues and friends that handles viral traffic without losing reliability or usage data. This is the shortest case study in the series for a reason: it shows how far a Service and a Relational Database can go on their own.
These five systems all solve the same underlying problem: serving content to far more people than ever create it. A blog, a photo gallery, and a search engine lean on caching to keep reads fast. A video platform and an internal AI search tool show where that playbook breaks: video needs its own storage and delivery strategy, and a knowledge base that changes constantly can't just be cached and left alone.
Blogging Application21:42Case Study 1
Designing a Blog Platform: Cache, Database, and File Store
Jasmine wants a simple blog where she can post travel stories and photos and readers can comment. The tricky part is not the writing, it is making sure thousands of readers can load her posts fast while only she can edit them.
Video Streaming Service16:01Case Study 3
How Video Streaming Actually Works: Chunking and Transcoding
Emily wants small creators to upload videos that stream smoothly for every viewer, on fast wifi or spotty cellular. Video breaks the caching playbook that works for text and images: it is too large to download at once and connectivity keeps changing mid playback.
Photo Gallery Application13:33Case Study 9
Designing a Photo Gallery: The Simplest System, On Purpose
Aaliyah wants a photo gallery to share her travel photos with fans. Only she uploads or edits. That single fact changes the entire design, and shows why more building blocks is not automatically a better system.
Search Engine Platform17:55Case Study 11
How Search Engines Rank Results: Inside a Ranking Service
Lamar wants to build a search engine for his library's digital archive: relevant ranked results, fast performance as the archive grows, and a way to keep expanding what is searchable. Ranking a result well means combining several different kinds of lookups fast.
Intelligent Knowledge Search17:15Case Study 14
Building an Internal AI Search Chatbot for Company Knowledge
Lyla wants a chatbot that answers employee questions from the company's internal knowledge base: policies, guidelines, training materials, all in natural language. The challenge is keeping an AI model current on a knowledge base that changes constantly.
These five systems all break the assumption that a request and a response happen once and you are done. A social feed, a collaborative doc, a chat app, and a video call have to keep multiple people in sync in real time. An AI chatbot has to hold state across a conversation that never really ends. Either way, the hard part is the same: state has to live somewhere between one request and the next.
Social Media Platform26:35Case Study 2
How Seniors Design a Social Media App: Feeds, Auth, Moderation
Alex wants to build a local community social platform, an MVP with profiles, groups, feeds, and content moderation. The hard part is not storing a post. It is making sure a feed with comments from dozens of followed people and groups loads instantly without recalculating it on every login.
Collaborative Document Tool17:06Case Study 4
Designing Google Docs: Real-Time Sync with CRDTs
Jordan is building a note-taking tool where remote teams edit the same document at once, sometimes offline, across time zones. The moment two people type in the same paragraph at the same second, a database alone cannot save you.
Generative AI Chatbot22:47Case Study 5
Designing an AI Chatbot System (Beyond the Model)
Sophia is building customer support chat for an e-commerce company: understand the question, answer from the product catalog, remember the conversation, and escalate to a human when needed. The AI model itself is stateless. Everything that makes it feel like a conversation is system design around it.
Chat Application13:17Case Study 7
Designing a Simple Chat App: When NOT to Over-Engineer
Ji Woo needs a dedicated chat app for a volunteer team spread across time zones, real time messages, secure logins, searchable history. The interesting design decision here is what NOT to build.
Video Conferencing System18:50Case Study 8
Designing Zoom for Courtrooms: The MCU Pattern
Michael needs a video conferencing platform for virtual court proceedings: every participant must see the exact same synchronized layout, on old courtroom hardware and modern devices, with every session archived for compliance.
These four systems all move real money, so a duplicate write is not a bug: it is a duplicate charge. A payment app and a live auction each show a different way to make one transaction happen exactly once. An online store adds the reporting layer that has to reconcile with those transactions after the fact, and a dynamic pricing engine adds a Worker that changes the price itself on a schedule.
Social Payment Application20:21Case Study 6
Designing a Venmo-Style Payment App: Fraud and 2FA
Arjun wants friends and family to split bills and send money to each other. Once real money moves, "close enough" is not good enough: every transfer needs to fully succeed or fully fail, and fraud has to be caught before funds move.
Online Store Platform18:45Case Study 10
Designing an Online Store: Reports On Demand and On Schedule
Sarah is turning her handmade jewelry business into an online store: manage products, process orders, take payments, and generate reports whenever she needs them or on a fixed schedule. The reporting requirement is the interesting design problem here.
Auction-Based Marketplace13:23Case Study 12
Designing an Auction Platform: Real-Time Bidding Systems
Liam wants an online auction platform for rare books, furniture, and art, where buyers bid in real time and see the highest bid update instantly. A relational database is not fast enough for bids that can land milliseconds apart.
Dynamic Pricing Marketplace19:09Case Study 13
Designing Dynamic Pricing Without AI (Just Rules)
Bronwyn wants a marketplace where prices automatically adjust based on demand and inventory, plus real-time notifications and analytics on sales trends. The pricing engine here is not a machine learning model. It is a Worker running rules on a schedule.
Watching the design is the free part. Building the judgment is the course.
Each case study shows a finished design. The courses put you on the other side of it: the same kind of requirements, but this time you own the design decisions, submit your own architecture, and find out exactly where your reasoning held and where it didn't.
