Dhamana

Fair-drop ticketing where the database itself guarantees no oversell, no double-sale, no unverified buy — enforced at commit on Aurora DSQL, across regions, at flash-drop scale.

Comment

Inspiration

Every painful ticketing failure — overselling a show, bots sweeping a drop, the same ticket sold to three people, refund leakage — is enforced today in fragile app code that bots route around and that diverges across regions. I wanted fairness to be something the database guarantees, at commit, not something an application layer promises and a stampede breaks.

What it does

Dhamana is a fair-drop ticketing engine. Under a flash-drop stampede it cannot oversell a seat, cannot resell a ticket twice, and cannot let a fan buy without a verified-fan record — each one enforced at COMMIT on Amazon Aurora DSQL across active-active regions. It holds throughput at scale by sharding the inventory counter, so a single hot seat row never becomes the bottleneck.

How we built it

Next.js (App Router) on Vercel routes through to Aurora DSQL via the postgres driver with @aws-sdk/dsql-signer IAM auth tokens. The load-bearing transactions — buy-and-hold, release/refund, verify, and escrowed resale — are each written once and run unchanged on three backends: an in-process OCC engine, Postgres SERIALIZABLE, and Aurora DSQL. Each is wrapped in retry-on-40001 tuned for flash-drop contention, with short jittered backoff that retries conflicts only and never retries a business error.

Inventory is sharded into N section_stock_buckets so the contended write spreads across buckets instead of one hot row; SUM(remaining) is the seats left, and a live throughput chart shows the difference. The whole thing was designed around DSQL from line one: commit-time OCC 40001, FOR UPDATE treated as a no-op so mutual exclusion comes from the write, client-generated UUIDv7 keys, CREATE INDEX ASYNC, and the transaction and connection limits respected. The Vercel functions deploy to a single region (iad1); it's DSQL that spans us-east-1 and us-west-2 with a us-east-2 witness, so the database is what carries the multi-region story.

The UI is editorial-kinetic, mirroring the back end: the seatmap is the contested inventory row depleting live, the checkmark is the verified-fan badge row, the resale slider hits a DB-enforced price cap, and the escrow balance settles as the ledger reconciles.

Challenges we ran into

Making a consistency win visible, since nothing happening is the whole point. The fix is a naive-vs-guarded toggle that manufactures the exact oversell DSQL prevents, then shows it prevented from both regional endpoints. The instructive part: a naive count-then-insert oversells because two buyers both read zero and insert different rows, so nothing conflicts. It reproduces reliably on the in-process engine; under DSQL's snapshot isolation the same window is narrower and timing-dependent, which is exactly why the fix is to contend on a shared counter row rather than rely on the read. The same lesson drove the per-buyer cap onto a contended counter instead of a count(*).

Accomplishments that we're proud of

Oversell, double-sale, and unverified purchase made architecturally impossible; a DB-enforced resale price cap rejected at commit rather than clamped in the client; a reconciliation invariant (held + Σrelease + Σrefund = Σhold) that holds identically from either regional endpoint; and a measured scale story where one hot bucket sheds buyers under load and 64 buckets serve them all with zero oversell.

What we learned

DSQL rewards designing with OCC: contend on the contested row, retry 40001, shard hot counters, and never trust FOR UPDATE.

What's next for Dhamana

Real identity and KYC behind the same gate; real payment rails behind the same escrow; and an af-south-1 endpoint as DSQL multi-region coverage expands.

Built honestly (what's mocked)

Payments and settlement (escrow is a ledger abstraction), identity and KYC (an evidence_url), and currency conversion (a single display currency). I don't claim to stop off-platform scalping — real identity behind the same gate is the named next step.

Where else this engine fits

The same commit-time invariants power any contested-scarce-resource-at-scale market:

  • Sneaker and streetwear flash drops (~$10B+ resale GMV, 100k+ concurrent).
  • Airline seat and hotel room inventory (overbooking is a recurring scandal).
  • Console and GPU restocks — verified-buyer gate plus sharded counter against bot armies.
  • Appointment and reservation systems at national scale (no double-book).
  • Carbon-credit and RWA registries (no double-count, idempotent ledger).
  • Limited digital collectibles (no double-mint, without blockchain cost).
  • Esports entry and scarce in-game items (100M+ players, global drops).
  • Government permit and benefit allocation (legally-required fairness).
  • Cross-border marketplace escrow (verification-as-a-row across regions).
  • Quota-bound governance voting (no double-vote, no over-allocation).

Built With

Share this project:

Updates