OmniDrop — The Concurrency Proxy for Flash-Sale Commerce

Inspiration

When a hyped sneaker drops or a limited event opens for booking, thousands of buyers click "Buy" in the same instant. Traditional storefronts handle that final unit with pessimistic row locks: every request queues behind a SELECT ... FOR UPDATE. Under a real spike, those locks saturate and the platform falls over — and the failures that leak through are the expensive kind: oversold inventory, double-bookings, mass refunds, chargebacks, and customers who never come back.

We kept seeing the same root cause: the moment of peak concurrency is exactly the moment the database is least equipped to stay correct. We wanted to put a purpose-built layer in front of that moment — one that treats the contended unit of inventory as a distributed consensus problem, not a lock to be queued behind. OmniDrop is that layer, built end to end on the v0 + Vercel + Amazon Aurora DSQL "Zero Stack."

What it does

OmniDrop is a B2B SaaS concurrency proxy that sits between flash-sale buyers and a merchant's existing storefront (Shopify today, Magento-ready).

• A merchant connects their store over OAuth and selects a product variant to run as a "drop."
• Buyers check out on an edge-deployed page instead of hammering the merchant's storefront directly.
• Each checkout is adjudicated by Aurora DSQL's Optimistic Concurrency Control (OCC). When two buyers race for the last unit, the database's serializable isolation lets one commit and rejects the other with SQLSTATE 40001 — no row locks, no oversell, no phantom orders.
• After the spike subsides, OmniDrop reconciles every secured order back to the merchant's real platform API under a strict, rate-limited drain, so the storefront is never the bottleneck during the rush.

The net effect: the merchant's platform is shielded from the concurrency storm, and inventory correctness is guaranteed by the database itself rather than by hope.

How we built it

Passwordless data plane (the part we're proudest of). OmniDrop never stores a database credential. Vercel injects a short-lived OIDC token for the deployment identity; @vercel/functions/oidc exchanges it for temporary AWS STS credentials by assuming an IAM role; @aws-sdk/dsql-signer mints a 15-minute Aurora DSQL auth token that becomes the Postgres password per connection. The pg pool's password field is a function, so every new connection gets a fresh token, and attachDatabasePool ties the pool to Vercel's serverless lifecycle. There are zero secrets in the repo, zero VPC wiring, and zero IAM YAML — the security architecture is the platform integration.

A data model designed for DSQL, not ported to it. Aurora DSQL intentionally drops features that don't scale in a distributed engine, so our Drizzle schema is built around those constraints on purpose: UUID primary keys via gen_random_uuid() instead of sequences, referential integrity enforced in the application layer instead of foreign keys, no triggers, and async index creation. Inventory is deliberately modeled as a single contended row per drop — the precise surface where DSQL's OCC has to do its work.

An OCC transaction engine, not a retry afterthought. The checkout server action wraps the BEGIN → SELECT → UPDATE → INSERT → COMMIT transaction in a retry loop that catches 40001 serialization failures at commit time and retries with exponential backoff (50/100/200ms). The order insert and the inventory decrement share one transaction, so an aborted race rolls back both — exactly-once order creation by construction.

Real reconciliation, real platform writes. When the drop ends, the reconciliation engine reads secured orders from DSQL and creates real orders on the merchant's platform through the Shopify and Magento Admin APIs (lib/platform-orders.ts). Shopify access tokens are validated and transparently refreshed per merchant (Shopify's expiring offline-token model), the drain is paced as a leaky bucket inside Shopify's ~2 req/sec ceiling, genuine 429 Retry-After responses are honored with precise back-off, and the platform's returned order id is persisted back onto the order.

A front end designed against the back end. We used v0 to build both the B2B merchant dashboard and the consumer checkout. The simulator is intentionally an executive, data-dense console: split buyer panels, live metrics, and a terminal event viewer that streams the raw transaction events and SQLSTATE codes from both racing checkouts. The UI exists to make the database's behavior legible — the front end is a window onto the back end, not decoration over it.

Challenges we ran into

The hardest shift was unlearning pessimistic locking. Our first instinct was SELECT FOR UPDATE; Aurora DSQL deliberately doesn't lean on that pattern. We had to move conflict handling up into the application compute layer — catching 40001 at the commit boundary and owning the retry policy ourselves. The second challenge was the credential model: getting comfortable that "no password anywhere" was correct and not a missing config, and structuring the pool so a fresh signed token is minted per connection without re-instantiating on every request. Lazy pool initialization mattered here, because the integration env vars only exist at request time, not at module load.

Accomplishments that we're proud of

• Zero oversell, proven live. The simulator fires two buyers at the same unit simultaneously . One commits with 00000; the other aborts with 40001 and is handled cleanly. The terminal shows the full interleaved event stream, so the guarantee is demonstrated, not asserted — and the same engine generalizes to N concurrent buyers because correctness is enforced by the database, not the request count.
• A genuinely passwordless production path from Vercel identity to Aurora DSQL.
• An end-to-end real write path — OAuth in, OCC arbitration, and reconciled orders back out to the live platform API with proper rate-limit handling.

What we learned

The "Zero Stack" changes the unit of work. By pairing v0's UI generation with Vercel's marketplace provisioning of Aurora DSQL, a small team architected a full-stack Project without leaving the workflow to manage VPCs, network routing, or stored credentials. The deeper lesson was conceptual: DSQL pushed us to treat the last unit of inventory as a consensus decision and to design both the schema and the application around optimistic concurrency from the first line, rather than bolting it on.

What's next for OmniDrop

Because Aurora DSQL decouples application compute from database topology, our Next.js codebase is already region-agnostic; moving to a multi-region active-active deployment is an infrastructure change, not a code rewrite. Next we plan to add webhook-driven reconciliation and first-class adapters for more headless platforms (Magento and WooCommerce), turning OmniDrop into a plug-and-play concurrency proxy for any storefront that can't afford to oversell.

Built With

• amazon-web-services
• dsql
• v0.app
• vercel