Start with the data you need to share
Pick a familiar structure. Use its behavior under concurrent updates to identify the causal machinery you need to understand.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
Learn the behavior before the bookkeeping
A counter, set, register, and map each makes a different promise when updates are delivered late or in a different order. Start with that promise. Then open the metadata that makes it possible.
- Counters
- Independent increments can combine because addition does not need a winner.
- Sets
- Removal needs a rule for additions that were observed, concurrent, or replayed later.
- Registers
- Concurrent writes force a choice: select one value or preserve every sibling.
- Maps
- Each key composes one of those conflict rules into a larger state model.
From merge behavior to causal evidence
Start with two structures that expose the problem. Then inspect dots, histories, orders, and clocks in the context of the behavior they support. All seven sheets include an article and a deterministic lab.
- Multi-value registers Read now
- Observed-remove sets Read now
- Dots and causal context Read now
- Local history Read now
- Partial order Read now
- Lamport clocks Read now
- Vector clocks Read now
Open the machinery when you need it
When a structure keeps a concurrent value or rejects a stale replay, inspect the dots, causal context, and clocks behind that result. The mechanism is attached to a concrete question instead of presented as vocabulary to memorize first.
Every explanation and diagram works without JavaScript. The browser labs let you delay a message, make concurrent updates, and inspect the exact state that explains the merge result.