Product database: Amazon Aurora DSQL — the only database the product runs on. DynamoDB appears solely as a removable benchmark foil; remove it and every feature still runs on DSQL alone.
One AWS database — Amazon Aurora DSQL — holding a worldwide ticket on-sale together. The DynamoDB toggle is a comparison foil that runs the identical code so you can watch eventual consistency oversell the same seat. It is not part of the product: remove the foil and every feature — seat map, buy, My tickets, Break-it, the Witness — still runs on DSQL alone.
A worldwide ticket on-sale where one seat must sell to exactly one fan. Click any open seat to buy it — you get a confirmation code and it appears under My tickets. Then press Break it to simulate a real on-sale stampede: dozens of fans hitting the same seat in the same second from two regions. The contrast is honest — both backends run the same naive read-then-write code; only the database's consistency model decides whether that seat gets sold twice.
2-region active-active · us-east-1 + us-east-2 — click any open seat to buy it, or fire a stampede at one seat with Break it →
No tickets yet. Click a seat and press Buy.
oversold is counted straight from committed table state — the DSQL op_log and the append-only DynamoDB sales_naive ledger — never from what the app hoped happened. The naive seats table shows a single owner (last-writer-wins hides the damage); the ledger is the ground truth of how many people really hold that one seat. Dollar figures multiply that measured oversold count by a $150 face value — a representative major-event ticket price; it scales linearly, so the exact dollar amount is illustrative while the oversold count itself is the measured fact.