System Design line, station 7 of 8Architecture line, station 2 of 4
System Design Case Studies
Learn to run a design review, then use it on three complete case studies at Mangrove Market: a URL shortener, offline sales sync from store tills, and ordering that never oversells.
- 4lessons
- 2.5 hto read and do
- Advancedlevel
- 4podcast episodes
- 6checked exercises
Tools you'll use in this course
The lessons open these with a template ready. They work for your own job too, no course needed.
About this course
This course is where the System Design track comes together. It starts with the meeting where real designs are tested: what to send before a design review, how to spend each minute, how to read an architecture diagram, how to turn an argument into a decision, and how to record it in an architecture decision record (ADR) so it stays decided.
Then you run three full reviews at Mangrove Market, the fictional grocery chain used across Kolom. A URL shortener for receipt and offer SMS, with base62 codes, 301 against 302 and click counting that never slows a redirect. A sales sync that brings every sale from about 400 store tills to head office exactly once, even when the internet drops for hours. And ordering for the Mangrove app and the Partner app that never sells the last carton twice, with holds that expire, an order state machine and payment webhooks you can trust.
Each case study goes from requirements and numbers to working code, a failure table and a rollout plan, and each lesson has a podcast episode. You practise the key pieces in auto-checked exercises in your browser: base62 encoding, idempotent inserts with ON CONFLICT, finding missing sales, conditional stock updates and order state checks. It is also the shape that system design interviews ask for.
What you will be able to do
- Lead a 45 to 60 minute design review that ends with written decisions, named owners and an ADR
- Turn a vague request into requirements, numbers with their arithmetic, an API and a data model
- Choose a short-code scheme, a redirect type and a caching plan for a read-heavy service, and explain the trade-offs
- Design an upload protocol from offline devices that survives lost replies and retries with no duplicates and no gaps
- Reserve limited stock with one conditional update and enforce an order state machine in code and in the database
- Fill in a failure table for any design, including payment webhooks that arrive late, twice or never
Syllabus
4 stops, about 2.5 h in total. Each stop fills in when you complete the lesson.
Running a design review
A design review is where a team finds the expensive mistakes while they are still cheap to fix. This lesson turns the thinking loop from What system design really is into a meeting you can lead: what to send before it, what to ask at each step, how to disagree well, and how to write the decision down so it stays decided. The three case studies that follow in this course are each run as one of these reviews.
Design reviewsDesign docs and ADRsFailure-mode analysis
Case study: a URL shortener
A URL shortener looks like a weekend project: store a long link, give back a short code, redirect. Done properly, it touches almost every idea in the system design track. We will walk through it as a real design review for Mangrove Market, step by step, from requirements to rollout, using the framework from Running a design review.
Short codes and redirectsBack-of-the-envelope estimationIdempotent ingestionFailure-mode analysis
Case study: syncing POS sales from hundreds of stores
Every Mangrove Market store keeps selling when its internet drops, and head office still needs every sale, exactly once, within minutes. This case study designs that pipeline as a full review: requirements, numbers, the upload and acknowledgement protocol, the tables, what breaks, and how you know a store has gone quiet.
Idempotent ingestionOffline syncBack-of-the-envelope estimationFailure-mode analysis
Case study: ordering without overselling stock
On the eve of a big festival, two hundred customers and partner shops want the last fifty cartons of cooking oil, and the payment arrives later from a card or mobile-wallet provider. This case study designs Mangrove Market's ordering so that stock is never sold twice, unpaid holds expire on their own, and every lost message, double tap and crash has a planned answer.
Stock reservationOrder state machinesPayment webhooksFailure-mode analysis
Capstone: Design review pack: proof of delivery for the Rider app
A realistic project with a rubric and a model answer.
Final exam and certificate
10 questions drawn at random, 70% to pass.
Capstone project
Design review pack: proof of delivery for the Rider app
Mangrove Market's 600 riders deliver about 60,000 app orders a day, and many customers pay in cash at the door. Today a rider taps "Delivered" and nothing else is recorded, so disputes and missing cash take days to sort out. Design proof of delivery: the Rider app records each handover (a photo, the time and place, and any cash collected) even on patchy mobile data, the store sees every delivery confirmed within minutes, and each store can reconcile every rider's cash at the end of the shift. Ken, the engineering manager, wants the pack ready for a real design review next week, with Imran as product manager and Nadia as decider.
You will hand in
- A design doc of 3 to 6 pages using the template from Running a design review: requirements, numbers with arithmetic, API, data model, one architecture diagram with labelled arrows, deep dives, alternatives and rollout
- A failure table with at least 8 rows, covering the phone, the network, your API, the database, object storage and a resent upload
- One ADR for your most important decision, with the options, consequences and revisit triggers
- SQL for the key tables and constraints, plus the statement that makes a resent delivery confirmation harmless and the query that finds cash mismatches
- A short review invite with the ask, the decider and what is out of scope
Check what you know
Already know some of this? Answer 4 quick questions, one from each lesson, and we will mark the lessons you can skim. It takes about 2 minutes and nothing is graded.
Questions
How long does this course take?
About 3 hours for the four lessons, including the checkpoints and practice exercises, plus 2 to 6 hours for the capstone if you do it. Each lesson also has a podcast episode of about 13 to 14 minutes.
What should I know before I start?
You should be comfortable with a web API and SQL basics, and able to read JavaScript or TypeScript. How the Web Works and SQL & Data Modeling are the recommended courses before this one. The case studies also use caches, queues, replicas and the outbox pattern; each lesson links to the lesson that teaches every idea it builds on, so you can fill gaps as you go.
Do I need to install anything?
No. Every practice exercise runs in your browser, SQL in a real PostgreSQL and JavaScript in a sandbox, and checks itself. To follow the Build-it sections on your own machine you need Node.js, Docker for Postgres 16 and Redis, and a code editor.
Will this help with system design interviews?
Yes. Each case study follows the same loop interviewers expect: requirements, estimates, API and data, a diagram, deep dives, failure modes and trade-offs. Every lesson has an "In interviews" box that names the usual question and what a strong answer covers.
Is the certificate free?
Yes. The lessons, podcasts, exercises, final exam and certificate are all free.
How does the final exam work?
Each attempt draws 15 random questions from this course's question bank, and you need 70% to pass. If you do not pass, you can try again after 24 hours. The questions are new scenarios at Mangrove Market, so understanding the ideas matters more than remembering the lesson text.
Is it really free?
Yes. Every lesson, podcast episode, exercise, quiz, final exam and certificate is free. The labs and their templates for real work are free too. Plus and Premium add every lab challenge, weekly extras and a mentor on top, and they never lock the tools or the courses.