DropLock: Global No‑Oversell Drop Engine

Global scarcity engine for game drops, ticket presales & fan events - Aurora DSQL enforces one worldwide inventory cap under flash-sale concurrency. Vercel + OIDC in prod.

Comment

Inspiration

Every flash sale shares the same nightmare: overselling. A limited drop goes live, thousands of buyers hit it at once, and the inventory count can't keep up. Two people buy the last item - then come refunds, chargebacks, and lost trust.

The naive fix - read a sold count, check the cap, write an order - fails under concurrency because many requests read the same stale number before any of them writes. Caches and read replicas make it worse. I built DropLock to show what a correct scarcity engine looks like: one global cap, enforced at write time, provable under flash-sale pressure.

What it does

DropLock is a global scarcity engine for high-demand, limited-inventory drops - game item launches, ticket presales, sneaker releases, creator merch, and fan events.

  • Buy Now reserves inventory in Aurora DSQL - not an in-memory counter
  • Stripe Checkout (test mode) on the demo drop - “Reserve $89 hoodie” through hosted checkout (4242… test card, no real charge). Payment is cosmetic; inventory still flows through the same DSQL reservation engine (no Stripe webhooks, no inventory authority handed to Stripe)
  • Idempotency keys so double-clicks, network retries, and Stripe return URLs never create duplicate orders
  • Per-buyer limits enforced under real concurrency
  • Integrity dashboard with a live Naive vs DropLock comparison: 500 concurrent buyers against 100 units, side by side on the same DSQL cluster

The naive path oversells (e.g. ~105–108 sold / 5–8 oversold on production DSQL). DropLock holds the line: 100 / 100 sold, 0 oversold.

How I built it

Frontend & API: Next.js 16 App Router on Vercel - stateless route handlers that scale horizontally with zero inventory state at the edge.

Production auth: Vercel OIDC → AWS IAM (AWS_ROLE_ARN) for Aurora DSQL signing in production - no long-lived IAM access keys on Vercel. Local dev uses a separate DSQL cluster with static keys; prod runs on the AWS Marketplace account with role-based credentials only. /api/health reports auth: "oidc" in production.

Database: Amazon Aurora DSQL as the single source of truth. Distributed PostgreSQL with serializable isolation and optimistic concurrency control.

Reservation engine (src/lib/reservation-engine.ts):

  1. Idempotency pre-check → return existing order on replay
  2. Per-buyer limit count inside a serializable transaction
  3. Random shard pick across 10 inventory buckets (avoids one hot row)
  4. Conditional UPDATE ... WHERE reserved_count < capacity - cap enforced in the database
  5. OCC retry loop on serialization conflicts (40001)

The standout design choice: the same serializable isolation that prevents global oversell also enforces the per-buyer limit — no extra locking code.

Commerce layer (demo-only): Feature-flagged Stripe Checkout (STRIPE_CHECKOUT_ENABLED) creates a test-mode session → user pays on Stripe’s hosted page → return URL calls /checkout/fulfill, which verifies payment_status=paid server-side, then invokes the same attemptReservation path as Buy Now. Stripe never touches inventory; there are no webhooks.

Proof path: A separate naive simulation (SELECT COUNT → INSERT, no capacity guard) runs real concurrent DSQL transactions in isolated demo tables, so the comparison is honest - not a rigged JavaScript counter.

Architecture

Challenges I ran into

  • Hot-row contention - a single inventory counter becomes a bottleneck under burst load. Solved with sharded reservation_buckets and random bucket selection.
  • OCC tuning - serialization conflicts spike when 500 buyers hit at once. Tighter exponential backoff and a connection pool sized for burst concurrency kept retries bounded without weakening the invariant.
  • Honest naive demo - I needed the comparison to fail for real on DSQL, not simulate failure in app code. That meant building isolated naive tables and running actual concurrent transactions against them.
  • Serverless + DSQL auth - wiring AWS credential signing for Aurora DSQL from Vercel route handlers without holding connection state across invocations. Production uses Vercel OIDC instead of static keys; STS getaddrinfo EBUSY under 500-buyer bursts required credential caching, pool warm-up, and batched DropLock paths while keeping full parallelism on the naive oversell demo.
  • Two AWS accounts - dev cluster in a personal account, prod on Marketplace/Vercel OIDC - without mixing credentials or weakening the demo invariant.

Accomplishments that I'm proud of

  • Provably zero oversold under a 500-buyer flash-sale burst on live Aurora DSQL
  • Side-by-side FAILED / PASSED integrity dashboard judges can reproduce in one click
  • Production deploy with OIDC - no IAM keys in Vercel env; DSQL auth via short-lived role credentials
  • End-to-end demo commerce - Stripe test checkout → success banner → DSQL reservation, without changing the engine or wiring inventory to webhooks
  • Full audit trail: every purchase attempt logged with outcome, conflict retries, and failure reason
  • Production deployment on Vercel with open-source repo and reproducible local scripts
  • Architecture built for Track 3: Million-scale global app - stateless Vercel + horizontally scalable DSQL + shardable inventory

What I learned

Aurora DSQL's serializable isolation catches many naive race conditions automatically - but it is not enough on its own. Without a conditional update at write time, apps still oversell. The fix is enforcing the cap inside the database, not in application memory.

I also learned that idempotency and per-buyer limits are not separate problems - they are both correctness properties that fall out of the same transactional design when you treat DSQL as the authority.

Shipping OIDC on serverless taught me that auth is part of the burst path: if STS is slow or flaky under concurrency, the reservation engine never gets a fair test. Caching credentials and warming the pool matter as much as the SQL.

For Stripe, the right split is clear: payment UX at the edge, inventory authority in DSQL. Webhooks can come later; the invariant must not depend on them.

What's next for DropLock: Global No-Oversell Drop Engine

  • Multi-region active-active drops on Aurora DSQL's global topology
  • Webhook notifications for sold-out and waitlist events (Stripe webhooks for receipts only - never for inventory)
  • Admin API for drop creation at scale (gaming studios, ticketing platforms)
  • Load testing at 10k+ concurrent buyers with dynamic shard scaling
  • Production Stripe (live mode) and platform embeds (Shopify, Discord, game launchers)

Built With

Share this project:

Updates