Skip to main content

Courses About Pricing Educators

Sign in Get started

Courses About Pricing Educators

Get started Sign in

Loading courses

Loading lessons

Consistency: System Design: Uncharted

Courses System DesignConsistency

ConsistencyPro

Choose what readers may disagree about, make retries safe, and bridge transactional boundaries honestly.

System Design
Unit 5 of 12
20 lessons
150 min
420 XP

This unit is part of Pro. Upgrade to open every lesson in it.

Lessons

20 total

1The Group Chat DisagreementRecognize temporary replica disagreement followed by convergence as an eventual-consistency behavior.ProInteractiveConcept7 min20 XPOpen
2Strong vs EventualChoose strong or eventual reads from the consequence of observing an older accepted state.ProInteractiveConcept7 min20 XPOpen
3Pick the ModelAssign consistency guarantees to money, scarce inventory, public counters, and freshness-bounded profile data.ProInteractiveConcept7 min20 XPOpen
4The Cut CableExplain why a partition forces an isolated side to sacrifice either write availability or a provable single state.ProInteractiveConcept7 min20 XPOpen
5CAP Without the MythsScope the CAP tradeoff to operations whose required nodes cannot communicate during a network partition.ProInteractiveConcept7 min20 XPOpen
6Eventual Is Not WhateverDistinguish eventual convergence from monotonic reads that keep one user from moving backward in versions.ProInteractiveConcept7 min20 XPOpen
7The Double ChargeIdentify a lost response after commit as an uncertain outcome that can turn an ordinary retry into a duplicate effect.ProInteractiveConcept7 min20 XPOpen
8Idempotency KeysReuse one operation identity so retries return the recorded payment result instead of charging again.ProInteractiveConcept7 min20 XPOpen
9Design the Safe RetryDesign an idempotent handler in which atomic key ownership determines whether to replay a result or perform the effect.ProInteractiveConcept7 min20 XPOpen
10An At-Least-Once WorldAccount for duplicate deliveries by making the receiving effect idempotent rather than assuming exactly-once arrival.ProInteractiveConcept7 min20 XPOpen
11Transactions, in One PlaceDraw the boundary of one database transaction without extending its atomicity to external systems.ProInteractiveConcept7 min20 XPOpen
12The Dual-Write BugLocate the crash gap created when durable state and its event are written in separate operations.ProInteractiveConcept7 min20 XPOpen
13The OutboxModel a transactional outbox that commits state with an event record before a relay publishes it.ProDiagramConcept10 min20 XPOpen
14Unwinding a BookingOrder a saga’s compensating actions when a later service step fails after an earlier local commit.ProInteractiveConcept7 min20 XPOpen
15The Version ClashUse optimistic version checks to reject a stale update instead of silently overwriting a concurrent edit.ProInteractiveConcept7 min20 XPOpen
16What Would Users NoticeSpend strict coordination where disagreement changes money, ownership, or scarce capacity.ProInteractiveConcept7 min20 XPOpen
17Napkin: Staleness BudgetConvert an accepted refresh interval into a staleness budget expressed at the requested order of magnitude.ProInteractiveConcept7 min20 XPOpen
18Mark the Strong PathSeparate a payment path that reads authoritative state from a feed path allowed to use stale copies.ProDiagramProject10 min20 XPOpen
19Explain IdempotencyExplain how one stable request identity makes retrying safe even when the first outcome is unknown.ProInteractiveConcept8 min20 XPOpen
20Consistency Mastery CheckApply safe consistency, retry, replica-routing, and transaction boundaries across several failure scenarios.ProInteractiveMastery check10 min40 XPOpen

Databases at Scale Queues and Streams