Distributed Transactions Under Fire: Building a Zero-Oversell Flash Sale Platform with Amazon Aurora DSQL

Transcript

1. SINGAPORE
2. Distributed Transactions Under Fire: Building a Zero-Oversell Flash Sale Platform with Amazon Aurora DSQL Yuuki Yamashita
3. Yuuki Yamashita Tokyo AWS Community Builder (AI Engineering) 2026 Japan AWS All Certification Engineer Featured in AWS Builder Center 4×4 Data & Analytics
4. 30 SECONDS That 's how long a limited drop lasts. Thousands compete for a handful of items. Sneakers. Concert tickets. Exclusive merch.
5. Two Ways Traditional Setups Fail I II DB becomes the bottleneck You over-provision and waste Thousands of concurrent requests hit the same rows. Race conditions cause failed or duplicate orders. OVERSELLS Scale up for the spike. Pay for peak capacity 24/7. The drop lasts 30 seconds. WASTED SPEND
6. ACT II Enter Aurora DSQL Serverless. Distributed. Strongly consistent. Amazon Aurora DSQL
7. Aurora DSQL ̶ in one breath Amazon Aurora DSQL A globally distributed SQL engine with strong consistency and optimistic concurrency control. 01 02 03 Serverless Strong Consistency Optimistic CC No instances. No capacity planning. Scales to zero between drops. No stale reads. No split-brain. Distributed by design. No row-level locks. Conflicts detected at commit time. Loser retries. No distributed locks. No cache coordination. No custom consensus logic.
8. Optimistic Concurrency Control (OCC) Buyer A BEGIN SELECT stock INSERT order COMMIT RESULT START TXN stock = 1 >0✓ ORDER CREATED SUCCESS Order Placed BEGIN SELECT stock INSERT order COMMIT RETRY → SOLD OUT START TXN stock = 1 >0✓ ORDER CREATED concurrent Buyer B OCC ERROR No Oversell No distributed locks. No consensus protocol. Conflict detected at commit time ̶ deterministic, zero-oversell allocation.
9. DROPZERO A live limited-drop flash-sale store Built to prove zero oversells is possible. 100 buyers. 10 items. 0 oversells. Simulated stampede ̶ every commit verified. Serverless end-to-end No servers. No connection pools. No ops. Strong consistency under burst OCC + Aurora DSQL ̶ no locks, no stale reads. Live demo ̶ dropzero.dev 0 oversells ACT III ̶ DROPZERO Open during this talk. Try it yourself.
10. DROPZERO Architecture Vercel Next.js Users HTTPS REST API AWS Lambda API + OCC Retry SQL / IAM Aurora DSQL Serverless SQL dedup check DynamoDB Idempotency Keys No connection pool required ̶ DSQL manages connections natively
11. The Buy Transaction 1 2 3 4 5 BEGIN SELECT CHECK INSERT COMMIT Start transaction Read stock FOR UPDATE (OCC lock) stock > 0? If not → Abort Write order record OCC validates no conflict → commit BEGIN SELECT stock WHERE id = ? if stock == 0: ROLLBACK INSERT INTO orders ... COMMIT
12. Retry Strategy: Exponential Backoff + Jitter Attempt 1 ~100ms + jitter OCC Error Attempt 2 ~200ms + jitter OCC Error Attempt 3 OCC Error ~400ms + jitter Attempt 4 or Sold Out Base delay Jitter Max retries doubles each retry prevents retry storms then → sold out 100 ms ±50% 3 Success (if retry lands)
13. Idempotency at the API Edge Client Lambda Receives request Extracts key POST /buy X-Idempotency-Key: abc123 DynamoDB Lookup idempotency key Key exists? YES Return Cached Same response as original NO Execute Txn Aurora DSQL transaction Store Key DynamoDB TTL: 24h Same key = same response. Network retries never double-charge Return 200 Order confirmed to client
14. ACT IV ̶ DEMO Live Demo Simulated Buyer Stampede 100 Concurrent Buyers 10 Items in Stock Will it hold the line? All hitting buy simultaneously Exactly 10 ̶ no more Zero oversells ̶ or bust dropzero.dev ̶ live demo ?
16. ACT IV ̶ RESULT Demo Result 10 / 10 Orders committed 0 OVERSELLS 100 Concurrent buyers DSQL held the line. 90 Clean "sold out" responses
17. What Broke ̶ Two Failure Modes CONNECTION MODEL IAM tokens expire every 15 min • Lambda reused connections without refreshing the token • Auth failures only appeared under concurrent load Fix: refresh token per execution context • Call generate-db-auth-token on every cold start • Never cache a DSQL connection across invocations RETRY STORM 100 buyers → ~90 retries → 3× load by Wave 3 Fix: exponential backoff + jitter Circuit breaker + max 3 retries, then honest sold-out Trade-off: more latency at cold starts and retries, for correctness under concurrency
18. When DSQL is the Right Call USE WHEN Bursty workloads Flash sales, ticket drops, product launches Global distribution needed Strong consistency across regions, no stale reads No ops team No instances, no patches, no capacity planning Serverless-first architecture Lambda + Vercel + DSQL ̶ zero servers end to end
19. When DSQL is the Wrong Call AVOID WHEN Heavy analytics Aggregations, full-table scans ̶ use Redshift or Athena Complex joins Deeply relational schemas with many multi-table joins Stored procedures or triggers Not supported ̶ move logic to the application layer Steady high-throughput OLTP Constant load ̶ provisioned instance costs less
20. The Cost Shape of a Serverless DB 1.2 DROP event 1 0.8 0.6 0.4 0.2 0 T-60m T-45m T-30m T-15m T-5m T-1m DROP T+1 m T+5 m T+1 5m T+3 0m -0.2 Se rverle ss (DS QL) Provisioned (alway s-on) Pay only for what you use ̶ cost matches a bursty, contention-heavy workload. T+6 0m
21. Three Takeaways I II III Design for retries from day one. You pay for usage, not capacity. Build idempotency keys in from the start. OCC is not magic Serverless DB changes your cost model Idempotency is nonnegotiable
22. Thank You Yuuki Yamashita ̶ AWS Community Builder, AI Engineering AWS Community Day Singapore ̶ 22 Aug 2026