Systems / 2026 / Live in the browser
Idempotency Lab
An Idempotency-Key middleware for node:http built to the IETF draft, and a seeded simulation of 200 customers retrying payments through a lossy network, with and without it.
01
The problem
A client whose reply never arrives cannot tell a lost request from a lost response, so it retries. If the server already charged the card, it charges again, and nothing in the logs looks like an error.
02
How I approached it
One transport-free planRequest() decides every request, so the node:http middleware and the in-browser console run the same code: 400 for a missing key, 422 for a key reused with another payload, 409 with Retry-After while the first is still running, and a byte-for-byte replay with Idempotent-Replayed once it finishes, per draft-ietf-httpapi-idempotency-key-header-07. Payloads are fingerprinted as canonical JSON with sorted keys, keys are scoped per credential, and in-flight records hold a lease with a fencing token so a crashed worker's key frees itself and its late write is rejected. A discrete-event simulation on a seeded heap replays the same lossy network against both servers.
03
The outcome
On the default seed the plain server makes 46 duplicate charges across 36 customers and the keyed one makes none, a result the tests check across 25 seeds. Zero dependencies, 25 tests including the middleware over real sockets.
Related work
Five rate limiting algorithms replaying the same traffic side by side, plus a node:http middleware that advertises quota with the IETF RateLimit headers.
A last-writer-wins CRDT with vector clocks and causal delivery, written from scratch, so three replicas can go offline, edit the same keys and reconverge without a server deciding anything.
A live-stream interactivity bridge: a server and bridge layer that turn viewer actions into real-time events.