SOFTWARE RELIABILITY / CONTROLLED EXPERIMENTS
System Wind Tunnel.
Put a failure under glass. Change one condition. See exactly what survives.
THE SAME LOAD. TWO DESIGNS.
Deterministic browser model · no external callsParticles follow scheduled attempts. Queue depth, writes, and duplicates come from the event model. The chamber shape is a visual metaphor.
AFTER EVERY ATTEMPT DRAINS
A timeout is not an undo.
The original write can survive a lost reply. Repeating the intention should return that order instead of creating another.
PULL ON ONE THREAD
Follow an intention.
Intention 01 Queued ▧ · Working ▰ · Reused ▰
Select an attempt to inspect its completion. A filled segment is modeled worker time; its striped lead-in is queue time.
Worker started
Worker 3 starts this attempt.
A SEPARATE, EXECUTED EXPERIMENT
Out of the model.
Into two real processes.
The local harness sent 24 concurrent HTTP requests for one intention to two Node workers sharing SQLite. This is a recorded run from this machine; the controls above do not rerun it.
6 assertions passed · v24.5.0
- unprotected: 24 concurrent requests cross two worker processes2 processes; 24 orders; 24 returned order IDs
- idempotent: 24 concurrent requests cross two worker processes2 processes; 1 orders; 1 returned order IDs
- A fresh process reuses the persisted orderHTTP 200; original order ID preserved
- Changed payload cannot reuse an idempotency keyHTTP 409; no new order
- Retry after a lost reply returns the committed orderConnection dropped after commit; retry HTTP 200
- All repaired experiments leave exactly two intentions2 persisted orders
Reproduce it and inspect the limits
node scripts/wind-tunnel-harness.mjsRecorded 2026-09-05 20:39:19 UTC. Source SHA-256: a31b7ae4df3cfdea61ae14a57a8c029596555c91c7e7a9565074fc37f3cdd65d
- No payment, external service, or production environment.
- Fixed fixture tenant; no authentication claim.
- SQLite serializes writes; this is not a distributed database benchmark.
- Restart is graceful; power-loss and filesystem failure are not tested.
The principle. Idempotency binds a stable intention key to a request fingerprint and an atomic write. A retry returns the original result; a changed payload is rejected. It prevents duplicate side effects within that boundary, while uncertainty, queue capacity, and external integrations need their own handling.
The person behind the project
A note from Luis.
My work spans payments and driver workflows, where a missing response is different from a failed action. This fictional order scenario makes that distinction easy to inspect. The browser replay is a simulation; the separate HTTP receipt identifies its recorded execution.
Who it helps
Engineers working on requests that may be retried.
Try this
Replay “A lost reply” and compare Duplicate writes in the unprotected and repaired versions.
See reliability in a document review