DropGuard

Inspiration

Limited drops are exciting, but they are also fragile. When hundreds of buyers rush for the final units at the same time, many checkout systems can oversell, cancel orders, or damage customer trust. I built DropGuard around one simple promise: sell exactly N units, never N+1.

What it does

DropGuard is a multi-region checkout reservation layer for limited inventory drops. Sellers can create a drop from the dashboard, buyers can reserve a unit from a clean buyer page, and the system audits its own correctness live.

The product includes:

• a homepage with live drops
• a distributed simulation showing 200 buyer attempts racing for 100 units
• a buyer reservation page
• a seller dashboard for creating drops
• a live self-audit panel showing available, held, sold, released, and oversold counts

The key proof is that oversold stays at 0, even when buyer demand exceeds available inventory.

How I built it

I built DropGuard with Next.js on Vercel, connected to Aurora DSQL as the strongly consistent database layer. Inventory is modelled as one database row per sellable unit rather than one shared stock counter.

When a seller creates a drop, DropGuard inserts the drop and creates the matching unit rows. When a buyer reserves, the reservation system claims one available unit and rejects excess buyers once all units are gone. The dashboard then reads live database counts to prove the system has not oversold.

The demo page simulates regional traffic across Ireland and London, while the database architecture uses Aurora DSQL active-active consistency with a Paris witness.

Challenges we ran into

The hardest part was making the system honest. It was not enough to show a nice frontend counter; the final result had to come from database-backed state. I had to handle idempotency, reset behaviour, clean demo runs, multi-region behaviour, and live dashboard stats without accidentally creating fake or duplicated counts.

Another challenge was making the project feel like a complete product rather than just a technical demo. That is why I added the seller dashboard, buyer flow, readable drop URLs, and self-audit stats.

Accomplishments that I’m proud of

I am proud that DropGuard demonstrates the full loop:

seller creates drop → buyer reserves unit → dashboard audits correctness → oversold stays 0

The /demo page shows 200 buyer attempts for 100 units and lands on exactly 100 accepted, 100 rejected, claimed 100/100, regions agree, and oversold: 0. The seller dashboard also makes the system usable without terminal seeding, which makes the project feel much more shippable.

What I learned

I learned how important database design is for reliability. A limited drop is not just a frontend problem; it is a consistency problem. Modelling inventory as unit rows made the correctness easier to audit and explain.

I also learned how to think about product storytelling: judges should be able to open the homepage, click through the product, and understand the technical proof without needing me to explain every line of code.

What’s next for DropGuard

Next, I would add seller authentication, brand-specific dashboards, payment provider integration, reservation expiry controls, analytics, and webhooks for commerce platforms. I would also expand the multi-region tests and add a public audit log so sellers can export proof that a drop did not oversell.

Built With

• aws-aurora-dsql
• aws-iam-authentication
• drizzle-orm
• github
• next.js
• node.js
• postgresql-style-sql
• react
• tailwind-css
• typescript
• vercel