LotZero, global live auctions with zero oversells

Global live auctions where the last lot can only be won once. Money runs on Amazon Aurora DSQL (strongly consistent), the social firehose on DynamoDB. Zero oversells, zero double-spends, proven live.

Comment

Inspiration

Real-time global commerce forces a brutal tradeoff. Put your money ledger in a single Region and it is correct but slow for everyone far away. Spread it across Regions with eventually-consistent NoSQL and it is fast but unsafe: two Regions can both sell the last item, and someone gets a refund email. I wanted to build the thing that is supposed to be impossible on a weekend stack: a worldwide live auction where the last lot can only ever be won once.

What it does

LotZero runs real-time auctions for the whole planet at once. Bidders anywhere compete for the same lot in the same millisecond, and the platform guarantees exactly one winner, money that is never lost or duplicated, and a truthful view in every Region. It supports English (ascending), Dutch (falling-price, first-claim-wins), and fixed-price drops, with live chat, presence, reactions, leaderboards, and a global activity feed. A built-in Proof page fires hundreds of concurrent claims tagged across five AWS Regions and measures the guarantee live.

How I built it

A two-plane architecture with a deliberate consistency boundary:

  • Money and scarcity (Amazon Aurora DSQL): wallets, bids, holds, settlement and limited inventory run as strongly-consistent, optimistic-concurrency transactions. DSQL's active-active, multi-Region strong consistency means contention resolves correctly with no cross-Region locks and no lost writes.
  • Social firehose (Amazon DynamoDB): chat, presence, reactions, leaderboards and the activity feed use a single-table design built for very high write volume, where eventual consistency is fine.
  • Front-end: Next.js deployed on Vercel; the home "How it works" section and the About and FAQ pages were built in v0. Auth to DSQL uses short-lived IAM tokens (no static password), and the same SQL runs locally on embedded PGlite and in production on DSQL.

Challenges I ran into

Aurora DSQL is PostgreSQL-compatible but deliberately different: no foreign keys, no sequences, no JSON types, exactly one DDL statement per transaction, and SELECT ... FOR UPDATE is an optimistic-concurrency conflict check rather than a lock. I modeled around all of it: application-generated IDs, referential integrity enforced inside the transactions, automatic retry on serialization conflicts, and async indexes applied out of band. Getting the "exactly one winner under true concurrency" invariant right, and proving it, was the heart of the work.

Accomplishments that I'm proud of

Measured correctness, not claims. Under 200 concurrent global claims on a real Aurora DSQL cluster, the system holds zero oversells and zero double-spends, with money conserved and no negative balances, every run. It is deployed and shippable, and an end-to-end test suite plus a contention load test gate it.

What I learned

Aurora DSQL turns a previously-hard problem (globally-consistent contention) into an ordinary CRUD app, which frees you to pair it with DynamoDB for the parts that just need to be fast and huge. Good architecture here is choosing the right database per job and drawing the consistency boundary on purpose.

What's next for LotZero

LotZero already runs end-to-end on the production stack today. Taking it from a working product to a public marketplace means: real payment rails (Stripe or Adyen) and KYC, anti-fraud and bid-sniping protection, WebSockets and DynamoDB Streams to replace polling, and flipping on the multi-Region peered DSQL cluster (the code is already wired for it).

Built With

Share this project:

Updates