R2 · Coordination & Consistency
Coordination —
atomicity first.
The foundation every later chapter builds on: a reliable queue is made of atomic moves and a lock lease.
Five patterns for getting concurrent access right — atomic read-modify-write, distributed
locking, the Redlock contrast, cross-shard consistency, and hash-tag co-location. The grounding is
EchoMQ (echo/apps/echo_mq): every state transition is one inline Lua script run
EVALSHA-first, the claim lease holds a job to one worker with attempts as its fencing token, and
the braced emq:{q}: keyspace keeps a queue's keys on one slot. The chapter closes by making an
Exchange Platform order placement atomic across runtimes. It comes before the queue chapters because a
reliable queue is built from atomic moves.
Why & when
echo/apps/echo_mqConcurrency breaks data in quiet ways: two writers read the same value and one update vanishes; a job meant for one worker runs on three; a multi-key change lands half-applied across cluster slots. Coordination is the discipline of making concurrent access correct — with an atomic operation that admits no interleaving, a lock that admits one holder, or a key layout that keeps related data together. Each pattern is a different answer to one question: who is allowed to change this, and when.
Lost update
Two writers read-modify-write one key and an update disappears — one inline Lua move closes the race.
One worker at a time
A claimed job must run on exactly one node — the lease admits a single holder until it lapses.
Surviving a failover
A lock that must outlive a node failure — Redlock's majority-of-N, weighed against its cost.
Multi-key on a cluster
Related keys that must change together — the braced hashtag keeps them on one slot.
Every pattern in this chapter narrows who may change a key, and when — until concurrent access produces one correct result instead of a race.
The patterns
five modules · one workshopFive teaching modules, then a workshop. Each module is a hub with three dives.
Atomic updates
Read-modify-write without a race; every state move is one inline Lua script.
Distributed locking
The claim lease and its attempts fencing token admit one holder.
The Redlock algorithm
A majority-of-N multi-master lock — a contrast with the single-Valkey lease.
Cross-shard consistency
Keep a multi-key change on one slot so it cannot tear.
Hash-tag co-location
Force related keys to one cluster slot — the hashtag is the queue name.
Workshop
Make an Exchange Platform order placement atomic across runtimes.
How to apply
name the race · the primitive followsThe hard part is matching the coordination primitive to the failure you are guarding against. Name the race you cannot allow, and the pattern follows.
There is no universal coordination primitive — only the one that matches the race you cannot allow.
The workshop
echo/apps/exchange · EchoMQ.JobsThe chapter closes with R2.06: make an Exchange Platform order placement atomic across
runtimes. Exchange.Gateway.parse_place/1 turns an untrusted request into a typed place command,
minting a branded ORD id at acceptance; the order is then admitted onto the
{orders} queue as one inline Lua script — a kind check, a duplicate refusal, the row write, and
the pending insertion happening on the server in one atomic step. It is idempotent on retry, never a torn
write, and needs no lock and no Redlock, because the script is the serialization.
The atomic move, in depth
The full Lua bundle, the EVALSHA / NOSCRIPT dispatch, and the worker-side lock plane — the
emq:{q}: protocol, taught in depth on the far side of the door.
The branded job, in the manuscript
Part III builds the bus the patterns apply: the three-field job hash state, attempts, payload,
the four sorted sets, and attempts as the fencing token.
Notes on Valkey. An inline Lua script runs atomically — no other command interleaves with
it — and every key it touches is declared in KEYS, so on a cluster the keys must share one slot;
the braced {q} hashtag is what guarantees it. valkey.io/topics/cluster-spec
Up next
R3–R8With atomicity in hand, the queue chapters can be built: a reliable queue is a set of atomic moves over the braced keyspace.
Reliable Queues
Wait, active, done, recover.
Time, Delay & Priority
The sorted set as a clock.
Streams & Events
The durable log.
Flow Control
Staying stable under load.
Data Modeling
How data lives in RAM.
Production & Ops
Running the tier at scale.
References
sources · relatedSources
- Redis — Distributed locksthe canonical write-up of SET NX PX locking, fencing tokens, and Redlock
- Redis — Scripting with Luaatomic multi-key transitions via EVAL / EVALSHA, the way every EchoMQ move runs
- Valkey — Cluster specificationCRC16 mod 16384 slots and the {hashtag} that co-locates a queue's keys
- Salvatore Sanfilippo — Is Redlock safe?the Redis creator's defence of the Redlock algorithm
Related
- R1 — Cachingthe previous chapter — the read path
- R0.2 — Valkey under the Exchange Platformthe EchoMQ bus these patterns ground in
- EchoMQ — the protocolthe atomic-Lua transaction model, taught in depth
- The Branded Component SystemPart III builds the branded EchoMQ bus these patterns apply