AWS Builder Center

Builder Center

Zero Oversells, Zero Servers: a global drop platform on Amazon Aurora DSQL

Zero Oversells, Zero Servers: a global drop platform on Amazon Aurora DSQL

I'll be presenting this build as "Zero Oversells, Zero Servers" at AWS Community Day Singapore 2026 (Aug 22, AWS Singapore office). This article is the written companion — come find me if you're attending.

Yuuki Yamashita

Cloud Engineer

The problem is one number

When a limited drop goes live, thousands of people press Buy in the same second. Overselling, double-booking, the site falling over — these look like different bugs, but they're one bug: losing track of a single number under global concurrency. Sell 101 units of a 100-unit drop and you've broken a promise to a real customer.
I wanted to know whether a database could make that impossible by design, rather than papering over it with queues. So I built DROPZERO: a drop platform that sells exactly its stock and not one unit more — no matter how many buyers hit it at once, or which Region they come from. The primary back end is Amazon Aurora DSQL; the front end is Next.js on Vercel.
  • Live demo: https://dsql-drop-app.vercel.app
  • Architecture: https://dsql-drop-app.vercel.app/architecture
  • Source: https://github.com/yama3133/dsql-drop-app
(Originally built for the H0 hackathon — Hack the Zero Stack with Vercel v0 and AWS Databases.)

Why Amazon Aurora DSQL

A single-Region database can keep a stock counter honest with one transaction. The hard part is doing it across Regions without giving up correctness. Most distributed designs force the classic trade-off: strong consistency or low latency or multi-Region writes — pick two.
Aurora DSQL lets DROPZERO refuse that trade-off. It's a serverless, distributed SQL database with multi-Region, active-active clusters that are strongly consistent — two Regional endpoints, one logical database, a synchronous commit quorum. A buyer in Tokyo and a buyer in Seoul racing for the last unit are resolved against the same truth: exactly one wins, and the counter never goes negative. Everything else in the product is built on that guarantee.

Architecture at a glance

  • Amazon Aurora DSQL — multi-Region cluster: Tokyo (ap-northeast-1) + Seoul (ap-northeast-2) as active peers, Osaka (ap-northeast-3) as the witness Region.
  • AWS IAM — a role the front end assumes to obtain a short-lived DSQL authentication token, minted per connection.
  • Vercel OIDC federation — the front end presents an OIDC token, assumes the IAM role, and gets DSQL credentials. No long-lived secrets live in the application.
  • Next.js on Vercel — the drop UI and the purchase/inventory API routes.
That auth path is the part I'd most encourage others to copy:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
import { AuroraDSQLPool } from "@aws/aurora-dsql-node-postgres-connector";
import { awsCredentialsProvider } from "@vercel/oidc-aws-credentials-provider";

const pool = new AuroraDSQLPool({
host: process.env.PGHOST!,
region: process.env.AWS_REGION!,
user: "admin",
database: "postgres",
port: 5432,
customCredentialsProvider: awsCredentialsProvider({
roleArn: process.env.AWS_ROLE_ARN!, // injected by Vercel
clientConfig: { region: process.env.AWS_REGION! },
}),
});
Let the managed OIDC → IAM → DSQL token flow own the credential lifecycle. Don't hand-roll DSQL tokens — the first evening I lost to "auth problems" was entirely self-inflicted.

A DSQL-native data model

Aurora DSQL is PostgreSQL-compatible, but it is not vanilla PostgreSQL. Three constraints shaped the schema:
  • No foreign keys — referential integrity is enforced in the application.
  • No sequences / SERIAL — primary keys are UUIDs (gen_random_uuid() works as a server-side default).
  • One DDL statement per transaction — migrations run statement by statement.
The schema is intentionally tiny:
  • products(id uuid PK, name, drop_name)
  • inventory(id uuid PK, product_id, stock) ← the whole drop hinges on this one row
  • orders(id uuid PK, product_id, user_ref, status, region)
Every buyer on Earth contends for the same stock cell. That contention is the product.

The core: never oversell

A purchase is a single transaction — check and decrement — and the interesting part is what happens when two collide. Aurora DSQL uses optimistic concurrency control (OCC): it detects the conflict at commit time and rejects the loser with SQLSTATE 40001 (or DSQL's OC000 / OC001). The application retries.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
const OCC = new Set(["40001", "OC000", "OC001"]);

async function purchase(productId, userRef, region, maxAttempts = 40) {
for (let attempt = 1; ; attempt++) {
const client = await pool.connect();
try {
await client.query("BEGIN");
const upd = await client.query(
"UPDATE inventory SET stock = stock - 1 WHERE product_id = $1 AND stock > 0",
[productId],
);
if (upd.rowCount === 0) { await client.query("ROLLBACK"); return "sold_out"; }
await client.query(
"INSERT INTO orders (product_id, user_ref, status, region) VALUES ($1,$2,'confirmed',$3)",
[productId, userRef, region],
);
await client.query("COMMIT"); // a conflict surfaces here
return "confirmed";
} catch (e) {
await client.query("ROLLBACK").catch(() => {});
if (OCC.has(e.code) && attempt < maxAttempts) {
await backoffWithJitter(attempt); // exponential + jitter
continue; // retry re-reads the latest stock
}
throw e;
} finally {
client.release();
}
}
}
A retry re-reads the latest snapshot. Once stock reaches 0, WHERE stock > 0 matches no rows and the request cleanly returns sold out. The conflict becomes the correct answer, not an error.

A multi-Region gotcha worth an hour of your life

When creating the multi-Region cluster, I assumed the witness had to be a US Region — a claim repeated in plenty of places online. us-east-1 and us-west-2 were both rejected. The witness must live in the same Region set as the peers; for an APAC cluster, that's Osaka:
1
2
3
aws dsql create-cluster --region ap-northeast-1 \
--multi-region-properties '{"witnessRegion":"ap-northeast-3"}'
# then create the Seoul peer and link the two cluster ARNs
Trust the API error, not the folklore.
The consistency demo writes to both Regional endpoints at the same instant. Stock = 1, one purchase to Tokyo and one to Seoul: exactly one confirms, the other is sold out, and both endpoints report the same final stock — strong consistency across Regions, with zero application-side coordination.

Does it hold at scale? (k6)

I pointed k6 at both Regional endpoints: 100 units in stock, 3,000 concurrent purchases, 50 VUs.
Retry budgetconfirmedsold_outerrorsfinal stock
8 attempts1002,810900
40 attempts1002,90000
  1. Oversell never happened. confirmed is exactly 100 and final stock is exactly 0 in both runs. The 90 "errors" in the first run were failed purchases (conflicts that exhausted the retry budget), never extra sales.
  2. Hot-row contention needs a real retry budget. A single stock row under 50 concurrent VUs generates many OCC conflicts; raising the ceiling from 8 to 40 turned those 90 errors into clean sold-outs. Idempotent, retryable transactions aren't optional here — they're the design.

Global from the first commit

A worldwide drop should read like home wherever you are. The UI ships in 8 languages — English, Japanese, Chinese, Korean, Spanish, French, Portuguese, and Arabic — with full right-to-left layout for Arabic (the interface mirrors; numbers and IDs stay LTR).

Takeaways

  • Lean on the managed auth path. Vercel OIDC → IAM → DSQL token means no secrets in the app and no token plumbing.
  • Respect DSQL's dialect. No FKs, no sequences, one DDL per transaction, fixed Repeatable Read isolation. Design with it, not around it.
  • Treat OCC retries as a feature, not error handling. They're how "never oversell" actually works.
  • Multi-Region witness = same Region set. Don't trust the "US-only" folklore; trust the API error.
Aurora DSQL gives you a single, strongly consistent source of truth across Regions. Once you have that, "never oversell" is just a small, careful transaction — for one buyer or a million, in Tokyo or São Paulo.
I'm giving the extended version of this — "Zero Oversells, Zero Servers" — at AWS Community Day Singapore 2026 (Aug 22), where I'll dig further into the OCC retry behavior and multi-Region failure modes. If you're in the region, come say hi.
Live: https://dsql-drop-app.vercel.app · Architecture: https://dsql-drop-app.vercel.app/architecture · Code: https://github.com/yama3133/dsql-drop-app
# amazon-aurora# serverless# databases# multi-region# vercel
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article