Building a Zero-Oversell Flash Sale with Aurora DSQL

On August 22, 2026, I spoke at AWS Community Day Singapore. The talk was called "Distributed Transactions Under Fire: Building a Zero-Oversell Flash Sale Platform with Amazon Aurora DSQL," and this is a report on how it went, plus the technical content I walked through.

First, the honest part. There were 11 people in the room, the smallest audience I've ever spoken to. A Kiro workshop was running in a parallel track at the same time, and most of the crowd went there instead. Nobody asked a question afterward either. Fewer people in the room somehow made me more nervous, not less. Silence after a talk carries its own kind of pressure.

Here's what I actually talked about.

A limited-drop flash sale, the kind you see with sneakers or concert tickets, usually sells out in about 30 seconds. Thousands of buyers hit a handful of items at the exact same moment. Traditional database setups fail this scenario in two distinct ways. Either the database becomes the bottleneck, where thousands of concurrent requests hit the same rows, race conditions creep in, and orders fail or duplicate. Or you over-provision to survive the spike, paying for peak capacity around the clock even though the drop itself lasts half a minute.

Amazon Aurora DSQL was my answer to both problems. It's a serverless, distributed SQL engine with strong consistency: no instances to manage, no capacity planning, and it scales to zero between drops. Reads are never stale, and there's no split-brain to worry about.

The core mechanism is optimistic concurrency control, or OCC. Instead of taking row-level locks, DSQL detects conflicts at commit time. Picture two buyers, A and B, hitting the same product at nearly the same instant. Both begin a transaction, both read the stock and see it's greater than zero, both insert an order record. Up to this point they look identical. The difference shows up at commit: buyer A succeeds, buyer B gets an OCC error, retries, and lands on a clean "sold out." No distributed locks, no consensus protocol, just a deterministic outcome decided at commit time.

To prove this actually works, I built a live demo called DROPZERO, a limited-drop storefront. The architecture is simple: a Next.js frontend on Vercel calls a REST API on AWS Lambda, which talks to Aurora DSQL over a SQL/IAM connection, with a DynamoDB table handling idempotency checks on the side. DSQL manages its own connections, so there's no connection pool to configure in Lambda.

The buy transaction itself is five steps. Begin, select the stock row, check if it's greater than zero and roll back if not, insert the order, commit. OCC does the real work at that last step, validating there's no conflicting write before the commit succeeds.

Now, the part I actually wanted to talk about the most: what broke in production. Working demos are the easy half of the story.

The first failure was in the connection model. IAM tokens expire every 15 minutes, and Lambda was reusing connections without refreshing the token. The auth failures only showed up under concurrent load, so nothing caught it during normal development. The fix was to call generate-db-auth-token on every cold start and never cache a DSQL connection across invocations.

The second was a retry storm. Out of 100 concurrent buyers, roughly 90 end up retrying after an OCC error. Retry them naively and the load triples by the third wave. I fixed this with exponential backoff plus jitter: a 100ms base delay that doubles on each retry, with ±50% jitter so retries don't pile up in sync. A circuit breaker caps it at three retries, after which the client gets an honest "sold out" instead of hammering the database further. The trade-off is more latency at cold starts and during retries, in exchange for correctness under concurrency. I'm fine with that trade.

For the live demo, I ran a simulated stampede: 100 concurrent buyers against exactly 10 items in stock. The result was 10 out of 10 orders committed correctly, 90 clean "sold out" responses, and zero oversells. DSQL held the line.

DSQL is a good fit for bursty workloads like flash sales and ticket drops, for cases that need strong consistency across regions, and for teams that want a serverless-first architecture without an ops team managing instances. It's the wrong tool for heavy analytics with full-table scans (Amazon Redshift or Amazon Athena handle that better), for deeply relational schemas with many multi-table joins, or for steady, high-throughput OLTP where a provisioned instance simply costs less. Stored procedures and triggers aren't supported either, so that logic has to move up into the application layer.

The cost shape tells the same story from a different angle. A serverless database spikes hard for the thirty seconds the drop is live and sits near zero the rest of the time. A provisioned instance draws a flat line at whatever capacity you picked, all day, every day. Paying for a 30-second event versus paying for 24 hours is the difference that graph makes visible.

Three things I wanted people to walk away with: OCC isn't magic, design for retries from day one. A serverless database changes your cost model, you pay for usage, not capacity. And idempotency keys are non-negotiable, build them in from the start rather than bolting them on later.

As for the 11 people and the silence afterward, I won't pretend it didn't sting a little to realize the Kiro workshop had pulled the crowd away. But a small room turned out to carry its own kind of nerves, quieter but no less real. Next time I get a slot in Singapore, I want a topic that can hold its own against whatever's running next door.