QueueProof
Run high-demand drops with DynamoDB-backed reservation correctness, cancellation promotion, and a public proof replay that verifies every allocation from raw ledger events.
- 1,000
- concurrent requests
- 100
- seats, zero oversell
- 6
- verified invariants
Single-table DynamoDB
PK/SK entities for merchants, drops, counters, waitlist, ledger, idempotency and proof.
Reservation critical path
TransactWriteItems with conditional counter updates and no hash-head mutation.
Replay proof
Ledger buckets are read after the drop, sorted deterministically and hashed into a final proof.
Concurrency simulation
1,000 requests, 100 seats, zero oversell
The simulation runs against the same service boundary as production logic and returns the invariant summary alongside a replayable proof hash.
How it works
A single-table ledger that proves itself
QueueProof stores merchants, drops, counters, waitlist, ledger, idempotency and proof records in one DynamoDB table. Correctness is enforced on the write path and verified again on replay.
- 01
Reserve
Each request hits the same service boundary as production. A single TransactWriteItems call conditionally increments a sharded counter and writes the reservation, so capacity can never be exceeded.
- 02
Append
Every confirm, waitlist, cancel and promotion is appended as an immutable ledger event with a deterministic ULID. The hash head is never mutated in the critical path.
- 03
Replay
After the drop, ledger buckets are read back, sorted deterministically and folded into a single hash chain. The replay recomputes every allocation from raw events.
- 04
Prove
Six invariants are checked against the replayed state and published as a public proof. Anyone can verify the final hash matches the recorded ledger.
Verified invariants
Every published proof asserts the following properties hold across the entire event ledger.
- Capacity invariant
- No oversell
- No duplicate confirmed user
- Waitlist order
- Promotion order
- Hash chain valid
Critical-path guarantees
- Atomic reservation
- Conditional counter + reservation write in one transaction.
- Idempotent requests
- Replays of the same request id resolve to the same result.
- Deterministic replay
- Ledger sort order is stable, so proofs reproduce byte-for-byte.