One million agents. One hundred units. Zero oversells.
When autonomous agents transact against real inventory and real budgets, the last unit is a race condition — and a financial liability. ZeroRace is the strongly-consistent commit kernel that makes it impossible to oversell, double-charge, or breach a spend mandate. Truth on Aurora DSQL, read plane on DynamoDB.
↘ the card runs a real 1,000-agent burst against Aurora DSQL. not a mockup.
Limited drop · 100 units
LIVE
100
% remaining
0
oversells
0
dup settles
$0.00
drift
// inventory holds at exactly 0 — never below
1M → 100
agents → units sold, exactly
0 / 0 / 0 / 0
oversell · dupe · drift · breach
585
OCC retries — bounded, surfaced
2 regions
Tokyo + Seoul, active-active
< 60s
DSQL cluster provision time
// measured on a real Aurora DSQL cluster — a 1,000,000-agent swarm sold exactly 100; a peered Tokyo↔Seoul run failed over mid-swarm.
The question every database person asks
“Why not just use Aurora PostgreSQL?”
Because the last unit is a multi-region race, and only Aurora DSQL settles it strongly consistent and active-active. We didn't pick it for the logo — we picked it for the one guarantee nothing else gives.
Single-writer Postgres
✕One primary takes every write
Cross-region writes funnel to a single region — latency + a single point of failure.
✕Row locks serialize the hot unit
A million agents queue on one lock for the last item. Throughput collapses under contention.
✕Replicas are eventually consistent
Read a replica and you can sell stock that's already gone. Stale by design.
✕Failover = promote + downtime
Seconds-to-minutes of write outage while a standby is promoted.
Aurora DSQL
✓Active-active, every region writes
Two regional endpoints both commit, strongly consistent — no primary to lose.
✓OCC, not row locks
Sharded claims run in parallel; a true conflict surfaces at commit as 40001 and retries another shard.
✓Strong consistency, always
Snapshot isolation across regions. You never read stock that isn't there.
✓Lose a region mid-swarm — keep selling
App-layer failover to the peer; commits continue, invariants hold. We demo it live.
→ The structural answer: multi-region, active-active, strongly-consistent writes under a high-contention agent swarm. That is the one thing only DSQL does — and it's the whole reason this product exists.
The race condition is the product risk
Three ways agent commerce silently breaks.
FAILURE 01
Oversold inventory
Two agents race for the last unit. Both reads see stock. Both commit. You ship what you don't have.
FAILURE 02
Double settlement
A timeout triggers a retry. The first call already succeeded. The card gets charged twice.
FAILURE 03
Busted mandate
An agent's spend cap is checked, then drifts. Concurrent debits push it past its budget.
The guarantees
Each one is a database invariant, not a promise.
0
Never oversell
A conditional decrement the DB refuses to take negative. The commit that would break it loses the OCC race and retries another shard.
0
Never double-charge
Every settlement carries an idempotency key under a UNIQUE index. Replays are no-ops at the truth core — the ledger only moves once.
$0.00
Never breach a mandate
The spend cap is read and the debit applied in one atomic write. Σ of every ledger leg is zero — drift is structurally impossible.
The commit kernel
One idempotent ACID transaction does all of it.
No saga, no two-phase dance, no compensating writes. Inventory claim, mandate debit, double-entry ledger, and the outbox event all commit — or none do. Correctness is structural: a DB CHECK and a conditional UPDATE … WHERE rowcount, not advisory application logic.
Inventory and the budget are sharded across random-keyed buckets, so a 1,000,000-agent swarm never touches a hot row. The OCC retries you see on the right are real — we engineered for DSQL's model and surface the contention instead of hiding it.
BEGIN — POST /v1/purchases/commitATOMIC
1
01 · IDEMPOTENCY
SELECT response_snapshot FROM idempotency_registry
WHERE merchant_id=$1 AND idempotency_key=$2
→ Same key → the stored snapshot. Replays never move the ledger twice.
2
02 · CLAIM INVENTORY
UPDATE inventory_buckets SET available_qty = available_qty - 1
WHERE bucket_id=$1 AND available_qty >= 1
3
03 · DEBIT MANDATE
UPDATE mandate_buckets SET remaining_minor = remaining_minor - $1
WHERE bucket_id=$2 AND remaining_minor >= $1
We designed around DSQL's real model — and name it
The constraints aren't obstacles. They're the design.
Write conflicts as SQLSTATE 40001
OCC surfaces conflicts at commit, not via locks. The commit path is idempotent — retry with jittered backoff and the same key, reselect a shard.
High single-key contention discouraged
So nothing is single-key. Stock is pre-split across 64 random buckets, the budget across 20. There is no hot row to contend on.
No FOREIGN KEYs
Referential integrity lives in the service layer plus periodic audit queries — and the unique indexes are what make duplicate settlements provably zero.
Indexes build asynchronously
CREATE INDEX ASYNC, built before any traffic. The unique index IS the dupe guarantee, so it must be ACTIVE before the swarm runs.
Not a demo — a product you can use right now
Agent-safe checkout, behind one API call.
Sign up, get an API key, and POST /v1/purchases/commit — integrate in ~10 lines. Spin up your own merchants, spend mandates, and sharded inventory from a self-serve console. Billed per settlement: the correctness layer the agentic-commerce wave runs through.
A live operations console where every panel surfaces a real backend invariant. Unleash the swarm, fail a region, watch the counters stay pinned at zero.