Make it correct under failure: consistency and idempotency
Continues from the last build: A globally distributed system whose correctness under failure has been hand-waved: reads look fast everywhere, but nobody has said what happens when a region goes dark mid-write.
Edge caching and geo-routing made reads fast everywhere, but writes still land on a database that lives in one region while traffic arrives from five.
What you'll build
By the end: an ADR pinning Linkly's CAP stance per operation instead of one blanket claim, a per-operation consistency-level table naming the actual model and its scope, an idempotency-key design that makes a retried create return the same code instead of minting a new one, a partition playbook that states the exact behavior of every component when cross-region links drop, and a reconciliation design for merging state once the network heals.
See how we teach, before you sign up
You don't just get code dumped on you. Every starter file and every solution is explained line-by-line, in plain English. Here's one real file from this project:
# ADR-010: CAP Stance for Linkly ## Context <Describe the operation, its read/write ratio, and its regions> ## Options considered - Option A: CP (block on partition) - Option B: AP (serve stale, reconcile later) - Option C: Per-operation split (default choice) ## Decision <State the chosen stance and WHY, tied to a number: p99 latency budget, staleness tolerance in seconds> ## Consequences <What breaks, what a client sees, what ops must monitor>
Reading this file
# ADR-010: CAP Stance for LinklyOne ADR, but it must resolve per operation below, not as a single sentence.- Option C: Per-operation split (default choice)Almost never pick a single global stance; different operations tolerate different costs.## DecisionMust attach a number (seconds), not an adjective like 'fast' or 'consistent'.## ConsequencesName the client-visible effect, not just the internal mechanism.
Fill this once per operation, not once for the whole system.
That's 1 of 8 explained code blocks in this single project.
The build, milestone by milestone
- 1
Pin the CAP tradeoff to paper, per operation
4 guided stepsWithout this written down, the outage postmortem becomes 'we should have decided this earlier,' and the fix in production is a panic call about whether it's safe to fail open. Committing the tradeoff to paper before it's tested means the on-call runbook already has the answer.
- 2
Assign a real consistency model to every operation
4 guided steps'Consistency level' is not one dial. 'Strong' almost never means globally strong, it means linearizable within some scope, usually one shard leader. Naming that scope is what makes an SLA defensible in an incident review instead of a marketing claim.
- 3
Make create idempotent with an idempotency key
5 guided stepsRetries are guaranteed in a system spanning regions and mobile networks. If create isn't safe to retry, every timeout becomes a data quality bug, duplicate codes wasting keyspace, or worse, a silent overwrite of an in-flight code.
- 4
Define exactly what happens during a partition
5 guided steps'Undefined behavior during a partition' is exactly the failure symptom that turns a network blip into split-brain data corruption. Every component touching cross-region state needs one documented behavior for this case, decided in advance, not improvised at 2am.
- 5
Detect and reconcile after the partition heals
5 guided stepsA playbook that only covers 'during' the partition and not 'after' leaves silent divergence: abandoned locks that never got their record, and no active check that fail-closed create actually held. Reconciliation is the safety net that catches the case where the design itself had a gap.
What's inside when you start
You'll walk away with
This is portfolio-grade. Build it free.
Sign up to unlock every milestone step-by-step, the code skeletons, full reference solutions, and checkable tasks, with your progress saved as you build.
Start building