DropZero - Zero-oversell flash sales on Aurora DSQL

A daily flash-sale store that never oversells a single unit - even when thousands rush the same drop - built on Vercel v0 + Amazon Aurora DSQL.

Comment

Inspiration

Flash-sale and "deal of the day" commerce is everywhere - but it has a dirty secret: under a flash crowd, stores oversell. Two shoppers both buy "the last unit," and one of them quietly gets a cancellation email later. We wanted to build a real, monetizable store where limited stock means limited stock - provably - and where standing the whole thing up (a polished frontend wired to a database that scales) takes hours, not weeks. That's exactly the Zero Stack promise: front-end in minutes with Vercel v0, back-end designed for scale with AWS Databases.

What it does

DropZero is two commerce experiences in one storefront:

  • Daily Drop: one curated product goes live each day at a steep discount in strictly limited quantity - with a countdown, live stock counter, per-user limit, and timed reservations. The system guarantees zero oversell.
  • Full catalog: ~8,800 products across an 8-parent / 40+ subcategory tree, each with an image gallery, variants, price, and stock - with faceted browsing (price / brand / in-stock), infinite scroll, and product detail pages. Products are synced from supplier CSVs in Google Drive.

Shoppers sign in with a phone OTP, add to cart, and check out with Razorpay. It's a complete, monetizable store.

How we built it

  • Frontend with Vercel v0: the entire Next.js App Router UI (React Server Components, Tailwind, shadcn) was scaffolded with v0 and deployed on Vercel; merges to main auto-deploy.
  • Amazon Aurora DSQL as the database. The node-postgres pool's password is minted per connection as a 15-minute IAM token via Vercel OIDC - no static DB password or AWS key anywhere.
  • The oversell-proof claim engine: each drop's stock is sharded across N rows so concurrent buyers contend on different rows. A claim is a single OCC-retried transaction doing a conditional decrement (SET remaining = remaining - 1 WHERE remaining > 0 RETURNING) plus a reservation insert. DSQL fails conflicting commits with OC001; we retry the whole transaction. An idempotency key prevents double-allocation, and a Vercel Cron sweeps expired holds back into stock.
  • Catalog & taxonomy: a Google Drive CSV sync ingests Shopify-format exports per category, builds the parent/child category tree, and stores full image galleries and variants.

Challenges we ran into

  • Proving zero oversell. We built a load test that fires thousands of concurrent claims as distinct users; the invariant is successful claims must equal stock exactly. Getting there required sharded inventory + atomic decrement-with-reservation + OCC retries + idempotency.
  • Connecting without secrets. Wiring Vercel OIDC → AssumeRole → DSQL token-as-password took care - but the payoff is a deployment with zero long-lived credentials.
  • "Postgres-compatible, but not Postgres." DSQL has no foreign keys, sequences, triggers, arrays, or JSON columns, and allows one DDL per transaction. We embraced those constraints in the schema and migrations.
  • Messy real-world data. Supplier CSVs varied in format (some nested in subfolders), shared product names across categories, and packed multiple images/variants per product - all handled by the sync, batched to stay within serverless limits.

Accomplishments that we're proud of

  • Mathematically zero oversell under load - a 5,000-concurrent-buyer load test against limited stock produces exactly the right number of claims and zero oversold, every time.
  • No static secrets - database auth via short-lived, OIDC-derived IAM tokens.
  • A production-shaped store: 8,800+ products, hierarchical categories, faceted search, product detail with galleries/variants, OTP auth, Razorpay checkout, policy pages, and an Ops Console that reconciles inventory live from Aurora DSQL.

What we learned

Optimistic concurrency control is a feature, not a footgun. When you design for it - shard the contention, make the critical write conditional and atomic, and retry on conflict - you get correctness guarantees that are hard to achieve with traditional locking, and Aurora DSQL scales that pattern for you. Pair that with v0 generating a production-shaped frontend in an afternoon, and "front-end in minutes, back-end designed for scale" stops being a tagline.

What's next for DropZero

  • Per-variant inventory and back-in-stock alerts.
  • Order tracking and a seller dashboard with live drop analytics.
  • Search and recommendations across the full catalog.
  • Multi-region drops that lean further into Aurora DSQL's distributed, multi-AZ design.

Built With

Share this project:

Updates