DROPZERO

GIF
Load test with k6: 100 units, 3,000 concurrent purchases across Tokyo + Seoul → exactly 100 confirmed, 0 errors, 0 oversold.
Architecture: Vercel OIDC → IAM role → DSQL token, no static secrets. Aurora DSQL multi-Region (Tokyo + Seoul, Osaka witness).
GIF
Last-unit race: Tokyo and Seoul buy at the same instant. Tokyo confirmed, Seoul sold out — exactly one wins, stock never goes negative.

Inspiration

I kept watching limited drops oversell, double-book, and crash the moment they went live — and I wanted to know whether a database could make that impossible by design, not just patched over with queues bolted on top. When thousands of people press Buy in the same second, all those failures are really one failure: losing track of a single number under global concurrency.

What it does

DROPZERO is a global limited-drop platform that sells exactly its stock and not one unit more — no matter how many buyers hit it at once or which region they come from. Stock updates in real time, a purchase returns a confirmed order, and the UI ships in 8 languages including full right-to-left for Arabic. A buyer in Tokyo and a buyer in Seoul can race for the last unit at the same instant, and exactly one wins — the counter never goes negative.

How we built it

Frontend: Next.js (scaffolded with v0), deployed on Vercel.
Auth: Vercel OIDC federation → assume an AWS IAM role → mint a DSQL auth token per connection — zero hardcoded secrets.
Database: Amazon Aurora DSQL — serverless distributed SQL, multi-Region active-active and strongly consistent (Tokyo ap-northeast-1 + Seoul ap-northeast-2, witness Osaka ap-northeast-3).
Never oversell: each purchase is check + decrement in one transaction. DSQL uses optimistic concurrency control and rejects conflicting commits (SQLSTATE 40001); the app retries with exponential backoff. A retry re-reads the latest stock, so once it hits 0 the purchase cleanly returns sold out — the conflict becomes the correct answer.
Data model: products, inventory (the single hot row), orders. UUID PKs, no foreign keys, no sequences (DSQL constraints), integrity in the app.
Proven at scale (k6): 100 units, 3,000 concurrent purchases across both regions → exactly 100 confirmed, 0 errors, 0 oversold.

Challenges we ran into

Aurora DSQL is PostgreSQL-compatible but not vanilla Postgres: no foreign keys, no sequences, fixed Repeatable Read isolation, OCC. We designed the schema and transactions around that.
Multi-Region witness must be in the same region set. us-east-1 and us-west-2 were both rejected for an APAC cluster — the witness is Osaka. (Trust the API error, not the internet folklore.)
Hot-row contention needs a real retry budget. A single stock row under 50 concurrent VUs generated a lot of OCC conflicts; raising the retry ceiling (8 → 40) turned conflict errors into clean sold-outs at scale.

Accomplishments that we're proud of

Exactly 100 of 100 sold under 3,000 concurrent buyers across two regions — zero oversold, zero errors.
Cross-region strong consistency with zero application-side coordination.
No static secrets anywhere (Vercel OIDC → IAM → DSQL token).
A real product feel: live stock, tense drop UI, and 8 languages incl. RTL Arabic.

What we learned

Lean on the managed OIDC auth path — no token plumbing, no secrets.
Design with DSQL's dialect, not around it.
OCC retries aren't error handling — they're how "never oversell" actually works.