DropZero — zero oversells at global scale

• 

  thumbnail

• 

  architecture

Inspiration

I've been on the wrong end of overselling more than once — "your order is confirmed," then twenty minutes later, "sorry, it actually sold out." It happens because when thousands of people buy in the same second, the system loses count. I wanted to build the thing that makes that impossible — and run it on infrastructure that could take real traffic, not a toy.

When I saw Amazon Aurora DSQL on this stack — serverless, multi-region, strongly consistent — I realized it was exactly the right database for the problem. So I built DropZero: a flash-sale engine where overselling is mathematically impossible, even with thousands of buyers worldwide hitting the same drop at once.

What it does

A seller creates a "drop" with fixed inventory. When it goes live, buyers everywhere rush in, and every purchase atomically claims a distinct unit in Aurora DSQL — so the count can never go below zero. There's a seller console, a live global activity feed, seller analytics (revenue, sell-through, velocity), and a Consistency Console that fires thousands of concurrent buys on demand and shows the result live: confirmed, rejected, 0 oversold, integrity verified, and the optimistic-concurrency conflict rate.

How I built it

The front end is Next.js (App Router) + Tailwind, deployed on Vercel. The data layer talks to Amazon Aurora DSQL through the pg driver, authenticating with short-lived IAM tokens via @aws-sdk/dsql-signer — no stored passwords. I also built a zero-credential in-memory mode so the whole app runs locally before any cloud is wired up.

The heart of it is the claim engine: reserve() claims a random distinct unit row in one strongly-consistent transaction, wrapped in an OCC retry with jittered backoff, plus idempotency keys so a double-click never double-buys.

Challenges I ran into

I almost built it the obvious way — one remaining counter that every buyer decrements. On a normal database, that's fine. On Aurora DSQL's optimistic concurrency control, that single hot row is the worst possible workload: thousands of writes to one key produce a storm of 40001 serialization conflicts. So I flipped the entire model — every unit is its own row, and each buyer claims a random distinct one. Now thousands of buyers touch thousands of different rows, overselling is impossible by construction, and contention stays near zero. The flaw became the best part of the design.

DSQL also has real differences from PostgreSQL I had to design around: no foreign keys, no JSON, only one DDL statement per transaction (which is why my schema kept failing in the query editor until I ran each CREATE TABLE on its own), CREATE INDEX ASYNC instead of plain CREATE INDEX, and a 10k-row transaction limit (so I batch the unit minting).

And my first live stampede had a p99 of ~8.6 seconds — because my Vercel functions were in the US while my cluster was in Stockholm. Co-locating the functions in arn1 (same region as eu-north-1) dropped p99 to ~1 second.

What I learned

Distributed databases don't remove the hard parts — they move them into your data model. The single best decision in this project was turning one hot row into many cool rows. I also learned a lot about DSQL's optimistic concurrency, IAM-token auth, and what "strongly consistent at global scale" actually buys you.

What's next for DropZero

It isn't really about tickets. Anywhere a crowd grabs for limited slots at the same instant — university course registration, government visa / passport / appointment slots, vaccine and benefit sign-ups, ERP inventory allocation — is the same problem. DropZero is fair, oversell-proof allocation of any scarce resource, on infrastructure built to scale to millions.

Built With

• amazon-aurora-dsql
• next.js
• node.js
• postgresql
• react
• stripe
• swr
• tailwindcss
• typescript
• vercel