A thousand concurrent callers race to charge the same card — the way retries, timeouts and restarts really pile up in production. Press the button and count the charges.
Every dot is an agent calling charge(order_4471) at the same moment. With the fence on, exactly one executes; the other 999 wait and receive that result — not a second charge. Without it, you get the number you just watched climb in red.
The mechanism is a compare-and-swap on a fence token. One caller claims the key, everyone else finds it claimed. The winner records the result; the losers read it. There is no window between "check" and "act" for a second caller to slip through — which is the entire bug.
About the unfenced number. "Have we charged this already?" is normally a read against a flag that only gets written after the charge succeeds. Everyone who arrives inside that window sees "not yet" and charges. The button models a 50 ms write against callers arriving over roughly 100 ms — so about half land first. Widen the burst or slow the write and the number climbs; the shape doesn't change. Our own production version of this was smaller and just as real: one recipient got three identical emails from a deploy race.
Atomics barrier, elect exactly one execution on every commit. This page shows you the mechanism; the test suite is what proves it.
npm i once-kernel
import { OneDoor } from "once-kernel/door";
const door = new OneDoor();
await door.pass(
{ key: `charge:${orderId}`, payload: order },
() => stripe.charges.create(...)
);
// ran once, ever — retries replay the same result
One Door also answers two more questions at the same choke point: is there budget left? and may this tool run without a human? Same atomic check, one receipt.