Global scarcity audit
Aurora Launch Edition Hoodie
00000000-0000-4000-a000-000000000001
Global Inventory Invariant
PASSED
Key Insight
Million-scale drops need more than one inventory counter. DropLock shards the global cap across Aurora DSQL rows so concurrent reservations spread instead of colliding on a single hot row — and distributed transactions keep the cap strongly consistent worldwide.
System Explanation
Problem
Global scarcity events — tickets, game items, sneakers, creator drops — fail when concurrent demand oversells a shared cap.
Solution
DropLock uses Aurora DSQL with sharded reservations and distributed transactions so million-scale bursts cannot exceed configured inventory.
Guarantee
Successful reservations ≤ configured global cap — provable from the audit trail after every burst.
How this scales
Inventory shards
Each drop splits its global cap across shard rows so concurrent writes spread instead of hammering one hot counter.
Aurora DSQL transactions
Distributed, conditional updates enforce the cap inside the database. Successful reservations commit only when capacity remains.
Stateless Vercel API routes
Frontend and API handlers hold no inventory state. They scale horizontally while DSQL remains the single source of truth.
Audit trail after every burst
Purchase attempts, conflict retries resolved, and oversold units are recorded so the invariant can be verified after flash-sale load.
Inventory ledger
Configured cap
100
Global inventory limit for this scarcity event
Reservations confirmed
26
Committed orders in Aurora DSQL
Failed Attempts
0
Total rejected requests
Oversold Units
0
Must remain 0
Contention Under Load
Conflict Retries
9
Handled by the conflict retry mechanism during bursts
Reservation Conflicts Resolved
26
Conflicts reconciled without overselling
Rejected At Capacity
0
Requests denied when inventory shards are full
Inventory Shard Grid
Inventory is split across 10 inventory shards so concurrent buyers never fight over a single hot row. Each shard holds its own slice of the global cap.
26 / 100
global reserved
3 / 10
5 / 10
2 / 10
2 / 10
3 / 10
3 / 10
3 / 10
2 / 10
2 / 10
1 / 10
Naive vs DropLock
Traditional inventory counters break under global flash-sale pressure. DropLock is built for high-concurrency scarcity events — Aurora DSQL distributed transactions, inventory shards, and a conflict retry mechanism enforce the configured cap.
Invariant Proof
PASSEDPost-commit audit confirming purchases never exceed the global inventory cap.
The rule
Successful purchases must stay at or below configured inventory
Right now
26 purchases out of 100 units allowed
Result
PASSED — no overselling
Oversold check
0 unit(s) oversold
Architecture
Stateless Vercel API routes accept reservation requests at scale. Aurora DSQL shards the global cap and commits orders with distributed transactional integrity — no single hot inventory row.
- 1
Buyer Request
Millions of concurrent buyers worldwide
- 2
Regional API Route
Stateless Vercel handler, no inventory state
- 3
Aurora DSQL Transaction
Distributed, strongly consistent commit
- 4
Inventory Shard
Global cap split across shard rows
- 5
Order Commit
Reservation persisted transactionally
- 6
Invariant Audit
Sold ≤ cap proven after every burst
Demo only
Clear orders and purchase attempts, then restore full inventory so you can rerun the flash-sale simulation.