QueueProof

QueueProof helps merchants run limited-inventory drops with zero oversell and public proof.
Merchants create drops with capacity, SKU, and write-sharded counters.
The proof page verifies capacity, no oversell, waitlist order, and hash validity.
DynamoDB stores real reservation and idempotency records for each drop.
A single-table DynamoDB design stores drops, counters, waitlists, ledger events, and proofs.
QueueProof is deployed on Vercel and connected to DynamoDB-backed APIs.

Inspiration

High-demand drops are fragile.

When a merchant releases limited inventory — event seats, exclusive products, pop-up reservations, or collectible drops — demand can spike instantly. Under bursty traffic, many systems fail in the same way: they oversell inventory, accept duplicate reservations, or make allocation decisions that customers cannot verify.

QueueProof was inspired by a simple question:

Can a limited-inventory drop be fast, monetizable, and publicly verifiable at the same time?

QueueProof turns the reservation database into a correctness engine. Instead of only storing the final result, it records enough structured state and ledger events to replay the allocation afterward and prove that the drop respected its invariants.

What it does

QueueProof is verifiable drop infrastructure for limited inventory.

It lets merchants run high-demand drops without overselling, while giving customers a public proof page that verifies the allocation was fair, replayable, and tamper-evident.

In the production simulation, QueueProof runs:

1,000 reservation attempts
100 available seats
100 confirmed users
900 waitlisted users
0 oversells
0 duplicate accepted reservations
1,001 ledger events
A replayable final proof hash

The proof endpoint replays raw ledger events and verifies six invariants:

Capacity invariant
No oversell
No duplicate confirmed user
Waitlist order
Promotion order
Hash chain validity

How we built it

QueueProof is built as a merchant-facing B2B SaaS prototype using Next.js on Vercel and Amazon DynamoDB as the primary backend database.

The core design uses a DynamoDB single-table model with partition and sort key entities for drops, reservations, counters, waitlist entries, idempotency records, proof records, and ledger events.

The reservation critical path uses:

DynamoDB conditional writes
TransactWriteItems
Idempotency records
Write-sharded counters
Reservation records
Bucketed ledger event append

A key design choice was to keep the hash chain out of the hot reservation path. Instead of mutating a single global proof head during every reservation, QueueProof appends raw ledger events during the drop. After the drop, the proof endpoint reads ledger buckets, sorts events deterministically, replays the allocation, verifies the invariants, and computes a final proof hash.

This keeps the high-concurrency reservation path fast while still making the final allocation publicly replayable.

Challenges we faced

The hardest part was designing a system that was both concurrency-safe and explainable.

A naive design could use a single counter or a single ledger-head item, but that would create hot partitions or make the proof path too tightly coupled to the reservation path. We had to separate the write path from the proof path:

The write path enforces capacity and idempotency.
The proof path reconstructs and verifies the allocation.
The public proof hash makes tampering evident.

Another challenge was making the demo understandable in under three minutes. The project has real concurrency and database correctness logic, but the product value needs to be obvious quickly: one thousand attempts, one hundred seats, zero oversells, and a replayable proof.

What we learned

We learned that DynamoDB can be used as more than a storage layer. With conditional writes, transactions, sharded counters, and carefully modeled entities, it can act as the correctness engine for a high-concurrency allocation system.

We also learned that proof systems do not always need to be on-chain or cryptographically complex to be useful. For many real B2B workflows, a deterministic replay log, invariant checks, and a tamper-evident final hash can provide a practical and understandable verification layer.

What's next

Next, QueueProof could become a real merchant infrastructure product for limited-inventory commerce, event registration, pop-up reservations, and exclusive product launches.

Future work includes: