jonnify·persistence /echo-persistence/persistence-concepts/the-conditional-write-fence

Module 3 · Dive 3.3

The conditional-write fence.

The OCC commit kept one process honest. Off the box, the writers are different nodes — after a partition, two may both think they’re primary and both try to write commit LSN 7. The referee is the object store: create-if-not-exists lets the first PUT through and rejects the second. Toggle the fence off and watch what you lose.

§1

One key, one winner

interactive
Create-if-not-exists. Both nodes PUT the same commit object. With the fence on, the store creates it once (200) and rejects the rest (412). Turn the fence off and both writes succeed — the second overwrites the first.
Node A PUT commits/LSN-7 — Node B PUT commits/LSN-7 — fence: If-None-Match * Tigris · object commits/LSN-7 (empty)
readout · With the fence on, press PUT: A creates the object (200), B is rejected (412 Precondition Failed). Switch the fence off and both writes “succeed” — the second silently overwrites the first.
§2

Why this is the durability floor

graft.engine-split.design.md

The whole replicated design rests on this one atomic guarantee from the object store, and nothing more: a write that succeeds only if the key does not already exist. Both engines lean on it identically — the native one via Tigris’s conditional headers, the Rust one via OpenDAL’s if-not-exists, which surfaces the rejection as a precondition failure. That single primitive is what turns “append the next LSN” into a safe operation across nodes, with no lock service, no consensus cluster, no coordinator. Take it away — the fence-off case — and two primaries quietly diverge. With it, the page engines you meet in Chapter III are built on solid ground.

§3

References & sources