System Design line, station 5 of 8Architecture line, station 1 of 4
Distributed Systems
Learn how to keep data correct and apps working when your system runs on many machines that can disagree, fail and lose touch with each other.
- 5lessons
- 3 hto read and do
- Advancedlevel
- 5podcast episodes
- 7checked exercises
- 2simulators
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
As soon as an app has a read replica, a cache, a queue or a second service, its data lives in more than one place, and the network between those places will fail. This course teaches you what to do about that: how to choose between refusing and answering during a network split, how to set timeouts and retries that heal instead of harm, where to draw service boundaries, how to send events without losing them, and how to build apps that keep working offline.
Each lesson starts with an everyday picture, then explains the mechanism with diagrams and real numbers, and ends with a Build-it in NestJS, Postgres, Redis and BullMQ. You practise the core logic in auto-checked JavaScript and SQL exercises in your browser: quorum arithmetic, full-jitter backoff, a circuit breaker, an outbox relay query, an idempotent consumer and a field-level merge rule.
Every example happens at Mangrove Market, a fictional grocery chain with 320 stores, a Partner app for 1,800 corner shops and handheld scanners that lose signal in the backstore. The capstone asks you to make partner-shop ordering safe across stock, payment and delivery.
What you will be able to do
- Choose a consistency level per feature, explain it with CAP and PACELC, and check a quorum setting with R + W > N
- Set timeouts from real latency, retry only safe calls with full-jitter backoff, and protect dependencies with circuit breakers and bulkheads
- Decide between a monolith, a modular monolith and microservices, enforce module boundaries, and plan a strangler fig extraction
- Publish events reliably with a transactional outbox, run multi-step processes as sagas with compensations, and write idempotent consumers
- Design offline-first sync with device ids, a local outbox, a server change cursor, tombstones and conflict rules per field
Syllabus
5 stops, about 3 h in total. Each stop fills in when you complete the lesson.
CAP, PACELC and consistency
As soon as your data lives on more than one machine, the copies can disagree. This lesson gives you the words and the rules for that: what a system can promise when the network breaks, what it costs on a normal day, and how to choose the right promise for each feature.
CAP and PACELCConsistency modelsQuorums
Failure is normal: timeouts, retries, backoff and circuit breakers
Every call your service makes to another machine can be slow, fail, or never answer. This lesson gives you the five tools that stop one sick dependency from freezing everything: timeouts, careful retries, backoff with jitter, circuit breakers and bulkheads, plus the fallbacks that keep the user moving.
Timeouts and retriesBackoff and jitterCircuit breakers
Monolith, modular monolith, microservices
"Should we split this into microservices?" comes up in almost every growing team. This lesson shows what each shape costs, why a well-built modular monolith is the right default for a small team, how to draw boundaries, and how to pull a service out later without a big rewrite.
Service boundariesModular monolithsIncremental migration
Events, the outbox pattern and sagas
When one action must update your database and also tell other parts of the system, there is a gap where things get lost. This lesson closes that gap with the transactional outbox, shows how to run a business process across several services with a saga, and how to make every step safe to repeat.
Event-driven designOutbox patternSagasIdempotency
Offline-first apps and data sync
A store's internet drops. Handscanners walk into the backstore where there is no signal. An offline-first app keeps working on its own copy of the data and syncs when the network is back, without losing or doubling anything. This lesson gives you the moving parts: local storage, a local outbox, push and pull with a cursor, tombstones, and conflict rules that fit the business.
Offline syncConflict resolutionIdempotency
Capstone: Make partner-shop ordering safe across services
A realistic project with a rubric and a model answer.
Final exam and certificate
10 questions drawn at random, 70% to pass.
Capstone project
Make partner-shop ordering safe across services
Mangrove Market's Partner app lets about 1,800 corner shops order stock wholesale. Today one NestJS API saves the order, then calls the inventory service to reserve stock at the distribution centre, then charges the shop's mobile wallet, then sends an SMS, all inside one request with no timeouts. Last festival week, the wallet provider slowed to 12 seconds, checkout hung, some orders were saved but never reserved, and two shops were charged twice after retries. Ravi, one of the shop owners, now refuses to pay by wallet. Ken, the engineering manager, asks you for a short design and a working proof of the riskiest parts: what each step promises, how events are sent without loss, how failures are undone, how every outside call is protected, and what the shop owner sees while an order is still being confirmed.
You will hand in
- A 2 to 3 page design document with a consistency table: one row per feature, what it needs, where it reads from, and what happens when the primary is unreachable
- A saga diagram for placing an order, with every step, its event, its compensation, and which steps cannot be undone
- The outbox table, the relay's claim query and an idempotent stock consumer, with a test that delivers the same event twice
- A dependency table for the wallet, SMS and inventory calls: timeout, retry rule, backoff, breaker settings and fallback
- A one-paragraph decision on whether inventory should stay a module or become a separate service, with the specific reason
Check what you know
Already know some of this? Answer 5 quick questions, one from each lesson, and we will mark the lessons you can skim. It takes about 3 minutes and nothing is graded.
Questions
How long does this course take?
About 3 to 4 hours for the five 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 12 to 14 minutes.
What should I know before I start?
You should be comfortable with a web API, SQL basics and reading JavaScript or TypeScript. Databases at Scale (replication) and Scaling Building Blocks (caches and queues) are the recommended courses before this one, and each lesson links back to them when it builds on an idea.
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 and a code editor; the lessons run Postgres, Redis and BullMQ locally.
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.