DropZero -- proof-carrying flash drops on Aurora DSQL

Million-scale flash drops that never oversell — and prove it. Sharded Aurora DSQL kills the hot row; every run emits a portable capsule you verify yourself, no AWS. Live active-active multi-region.

Comment

Inspiration

Viral drops — concert tickets, esports passes, beta keys, premiere access — fail in the same boring way: under a flash crowd they oversell, and someone gets a quiet cancellation later. The usual reflex is to throw more servers at it, but that misses where the problem actually lives. Serving the reads is the easy half. The hard half is the one inventory row that thousands of people fight over in the same second — and that row does not get easier with more machines. It gets harder.

We wanted to build the honest version of this system: one that allocates each scarce unit exactly once under real concurrency and failure — and then produces evidence that it did, which anyone can check without trusting our app, our dashboard, or our word.

What it does

DropZero is a million-scale entertainment drop platform built on a proof-carrying database core.

  • It never oversells. Capacity is sharded across many allocation pools in Aurora DSQL, so concurrent buyers spread across the key range instead of contending on one counter. A guarded decrement plus a CHECK (allocated <= capacity) makes overselling structurally impossible, not merely unlikely.
  • Every run is verifiable. Each drop emits a portable evidence capsule — a JSON artifact with the committed events, a Merkle root, and the final allocation. A standalone verifier recomputes every invariant from scratch. Run npx dropzero-verify on your own laptop, with no AWS credentials, and it returns the same verdict we do.
  • It rejects bad runs. Tamper with a capsule — inject a fake order, flip an allocation, corrupt one audit leaf — and the verifier turns it INVALID and names the exact invariant that broke. It checks the arithmetic and the hash chain.
  • It's global and live. A real active-active Aurora DSQL cluster spans us-east-1 ⇄ us-east-2 with a witness in us-west-2. A write in one region is strongly consistent in the other on commit (~250ms in our probe), and concurrent claims against both endpoints still never oversell.
  • It proves why the design wins. A live benchmark races three database designs on the same workload — a single counter, regional reconciliation, and the DSQL kernel — and shows the tradeoffs instead of asserting them.

A judge console (/judge) ties it all together: run the race, watch the live ops panel, verify a capsule, tamper one, read the benchmark, and download the proof — in one place, in about three minutes.

How we built it

Aurora DSQL is the correctness kernel. All irreversible state lives there — events, sharded allocation pools, reservation holds, confirmed orders, a double-entry ledger, the audit log, and authoritative idempotency keys. A purchase is a single data-modifying CTE: pool allocation, hold, order, three balanced ledger rows, an audit leaf, and the idempotency key, committed together in one transaction (~2 round-trips). DSQL uses optimistic concurrency — conflicting commits return SQLSTATE 40001 — so a small retry wrapper re-runs the whole transaction with backoff.

DynamoDB is the real-time fan surface — activity feed and a metrics ring the live ops panel reads from. It is deliberately not in the correctness path.

Auth is credential-free — Vercel OIDC federates to an AWS IAM role and mints a short-lived, region-scoped DSQL token per request. No static secrets anywhere.

The UI was scaffolded with v0; the kernel, evidence layer, verifier, and benchmark were built by hand. We also model-check the core allocation protocol in TLA+ and ship an AWS FIS fault-injection template for the audit story.

Challenges we ran into

The most important one was a mistake we made and had to undo. Our first buy path recorded idempotency in DynamoDB and used a naive single-row counter for inventory. It looked reasonable — and it split the correctness boundary across two systems with no shared transaction. If the DSQL write committed but the DynamoDB update failed, the idempotency key was stranded forever: a wedged order with no recovery. The fix was to stop treating idempotency as a side effect and commit it inside the same transaction as the work, bound to a hash of the request inputs. That's the difference between a retry-safe workflow and a poisoned-key failure mode — and it's the reason the kernel is shaped the way it is.

We also learned that DSQL gives you no pessimistic locks — OCC is the only tool, which forces a design built around making conflicts cheap to detect and retry rather than expensive to prevent. And wiring live multi-region surfaced a subtle one: each regional endpoint needs an IAM token signed for its region (parsed from the host), or the second endpoint returns "access denied" — correct locally, broken in production until fixed.

Accomplishments that we're proud of

  • A measured, honest benchmark win: at 1,000 concurrent buyers, the kernel carries 92% fewer OCC retries (1,015 vs 13,383), 4.4× throughput, and a p99 of 35s vs 156s — zero oversold throughout, while the regional design oversells by up to 400 units.
  • A portable verifier that recomputes correctness offline, with no AWS — proof you take home, not "watch us run it."
  • Live, demonstrated multi-region (not diagrammed-and-claimed): ~250ms cross-region consistency and zero oversold across both endpoints, with the real cross-region tail latency shown honestly rather than hidden.
  • A submission where every live claim is true and every gap is labeled — MODELED, PLANNED, or WIRED LIVE — because the whole point is correctness you can check.

What we learned

Correctness is not the absence of failure — it's what remains true after failure, and you design for that by making retries and conflicts first-class, not exceptional. At million-scale, correctness isn't a feature you add after throughput; it's the shape of the data model itself. And the most credible thing a system can do is not claim it's correct — it's hand you an artifact and let you check.

What's next for DropZero — proof-carrying flash drops on Aurora DSQL

  • Complete the AWS FIS lifecycle once AWS ships a managed FIS policy for DSQL — the live injection already fires and the kernel holds 0 failures through it; only FIS's own close-out is blocked by the current preview-era gap.
  • Wire the DSQL CDC → Kinesis audit stream live (Kinesis is GA; the DSQL-native CDC feed is still preview).
  • Adaptive pool splitting that re-shards automatically under contention.
  • Fan-facing inclusion receipts — a Merkle proof per buyer.
  • A real payment-processor integration (payment intents + idempotent webhooks), DSQL as source of truth.

Built With

Share this project:

Updates