jonnify·bcs /bcs/bus/fence-and-keyspace/the-co-location-law

B3.1 · dive 3 — the co-location law

The hashtag is the queue.

F5 is the chapter's theorem. The hashtag is the queue name, so every key of one queue answers one slot — and every transition script this part will write stays single-slot legal on the clustered day, by grammar rather than by review.

Source: content/bcs3.1.md, quoting bcs_rung_3_1_check.out; the contrast figure for the payments queue and the specification vector stand in the appendix's record beside content/bcsA.md.

The slot table over the committed hashtags. The 16384-slot line, with the three committed figures placed on it. Select a queue — or the vector — to read its committed slot.
slot 0 slot 16383 {orders} slot 105 {fills} slot 4165 {payments} slot 8507 CRC16 vector 12739 holds
readout · Select a hashtag. One queue, one slot: every key type of a queue rides the one tag, so the whole family lands together — the arithmetic F5 asserts and the appendix froze first.
§1

The transcript

bcs_rung_3_1_check.out · verbatim · this dive reads F5
content/echo_data/runtimes/elixir/bcs_rung_3_1_check.out · verbatimfrozen
F1 map ok -- the part's map: emq:{orders}:pending | emq:{orders}:job:ORD0NgWEfAEJfs | {emq}:version | {emq}:locks -- 17 bytes before the payload
F2 gate ok -- the job position is gated: a fourteen-byte decimal and a fourteen-byte slug both raise before any wire is touched; kind policy waits for the enqueue script
F3 fence ok -- the fence holds on a live wire: GET {emq}:version answers echomq:2.0.0 through the fenced connector itself
F4 binary ok -- binary payloads with embedded CRLF and NUL survive 500/500 round trips through job keys in two pipelines
F5 slot ok -- co-location law: pending, active, meta, and the job row of {orders} all answer slot 105; {fills} answers 4165 -- multi-key scripts stay legal on the clustered day (vector 12739 holds)
PASS 5/5
§2

F5 — the theorem

content/bcs3.1.md · What · citing content/bcsA.md

The hashtag is the queue name, so every key of one queue answers one slot: pending, active, meta, and the job row of {orders} all answer slot 105; {fills} answers 4165 — and slot 105 is the same figure the appendix froze for the same hashtag, continuity across rungs by arithmetic rather than by intention. The appendix's record also holds the contrast figure: 8507 for the payments queue.

The consequence is the part's road ahead: hash tags exist to ensure that multiple keys are allocated in the same hash slot, which is what makes multi-key operations legal in a cluster — so every transition script this part will write (claim moves a job between pending and active; retry touches the job row and a schedule) stays single-slot legal on the clustered day, by grammar rather than by review. The vector 12739 holds for the client-side CRC16.

The legality checker. A pure model over the committed slot figures: a script's KEYS[] set is legal when its keys answer one slot. Select a script shape; the readout computes the slot set and the verdict.
readout · Select a script shape. The model collects the hashtags of the key set, maps each to its committed slot, and counts: one slot is legal, two is a design defect.

Static verdicts — claim → slot set {105}, legal · retry → {105}, legal · across two queues → {105, 4165} — the design is wrong before the script is.

§3

Committed, correct, and parked

content/bcs3.1.md · When · Boundaries

The slot function stays what the preface said: committed, correct, and parked, because single-instance is the part's stated topology. The connector does not speak cluster redirects, and teaching it MOVED is the clustered day's rung, not a hidden feature of this one. Mind the slot function's two lives: today it is partition arithmetic the connector can run without a round trip; on the clustered day it becomes routing, and the co-location law means the scripts written between now and then need no edits to survive the move.

Agents writing against the bus inherit one rule that prevents the whole category of cross-slot accidents: if a script needs keys from two queues, the design is wrong before the script is. Cross-queue choreography goes through the application, never through a multi-queue script.

§4

References

sources · related

Sources

Related