DropDeck

Inspiration

I kept hearing the same creator story, a small brand runs a limited drop, demand spikes in seconds, and they end up selling 65 units of a 50 unit product. Not because they made a mistake, but because the platform they trusted wasn't built for concurrent load.

That problem is completely solvable with the right database. Nobody had built a clean, accessible platform around it for independent creators. So I did.

What It Does

DropDeck is a flash-drop commerce platform where creators sell limited inventory through time-boxed drops with one hard guarantee: total orders can never exceed stock count, under any load.

• Sellers create a drop, set stock and start time, and walk away, it goes live automatically
• Buyers see a live stock count that reflects true available inventory, not a cached number
• Checkout is inline with Stripe no redirects, no friction
• Sold out means sold out, buyers get an honest response, not a spinner and a refund three days later
• Seller dashboard shows real-time sales, revenue, and sell-through time

How We Built It

Infrastructure: Vercel's v0 scaffolded the entire Next.js 14 app and provisioned Amazon Aurora PostgreSQL Serverless v2 in two clicks — no AWS console, no VPC configuration, no credential management. The checkout guarantee: Every purchase runs inside a single database transaction opening with SELECT ... FOR UPDATE on the drop record. That row-level lock serializes all concurrent checkouts at the database layer they queue, take turns, and each reads the true current stock before committing. Available stock is derived from committed order rows inside the transaction, never stored as a mutable counter. One source of truth. Always correct.

Stack: Next.js 14 · Aurora PostgreSQL Serverless v2 · NextAuth.js v5 · Stripe · Vercel Cron · Tailwind · shadcn/ui

Challenges We Ran Into

The hardest part was keeping the entire check-and-reserve sequence inside the transaction boundary. Any logic that leaked outside broke the guarantee.

Reservation expiry introduced an edge case , expired reservations only free stock when the Cron job runs, creating a one-minute window where a drop can appear sold out while units are about to free up. I resolved this by factoring expired order status into the available stock calculation explicitly.

Accomplishments That We're Proud Of

200 simultaneous checkout requests. 10 units of stock. Live on Vercel. Result: exactly 10 successful orders, 190 clean sold-out rejections, zero oversells.

That's not estimated. There's a reproducible load test running against production infrastructure.

I am also proud of what I didn't build, no Redis lock, no retry queue, no extra infrastructure layer. The right answer was already in PostgreSQL.

What We Learned

Picking the database for the workload, not for familiarity, changes what's possible. The no-oversell guarantee sounds like a distributed systems problem. It isn't, it's a transaction problem, and Aurora PostgreSQL is exactly the right tool for it.

v0 also changed something real: when infrastructure setup takes two minutes instead of a day, you stay focused on the actual problem the whole time.

What's Next for DropDeck

• Aurora DSQL for multi-region drops same no-oversell guarantee, globally
• Queue system for ultra-high-demand drops, fair wait room before checkout opens
• Subscription and transaction fee integration for automatic seller payouts and platform fee splits
• Demand analytics, sell-through curves and pricing signals for sellers

Built With

• aurora
• nextjs
• v0
• vercel