Stories · Season 2 — Frontrow · Episode 01

The Two People Who Bought the Last Seat

In which one seat is sold twice, two customers are delighted, and exactly one of them is about to be very unhappy.

The story

Frontrow sold tickets to live events, and for most of its life that was a calm business. Then a mid-size band announced a reunion show, a single venue, 1,200 seats, and the internet lost its mind.

At 10:00:00 the on-sale opened. At 10:00:01, two customers — let’s call them Customer A and Customer B — both clicked “Buy” on seat F-14, the last good seat in the house. Both requests read the database at the same instant. Both saw the seat as available. Both wrote “F-14: sold.” Both got a cheerful confirmation email with a little ticket emoji.

Mara, Frontrow’s lead engineer, found out the way engineers always find out: two people showed up to the venue holding a ticket for the same seat, and the usher called support. By then there was no clean fix. Someone was getting bumped, and no amount of apology email was going to make that feel okay.

“The code looked right,” Mara said, staring at it. And it did. Read the seat, check it’s free, mark it sold. The logic was fine. The timing was the problem.

Why this is hard the traditional way

This is a race condition, and it’s one of the most embarrassing bugs in software because the code reads perfectly. if (seat.IsAvailable) { sell(); } is correct exactly until two requests run it at the same microsecond. Then both pass the if, and both sell.

Teams reach for fixes that mostly make it worse. A lock in application code only protects one server — and you have six. A “check again right before writing” shrinks the window but never closes it. Hand-rolled SELECT ... FOR UPDATE works until someone writes the one code path that forgets it, and that path is the one that ships on a Friday.

The real issue: nobody told the database “this write assumes nothing changed since I read.” So the database happily lets the second writer stomp the first.

How Relay changes the ending

Relay’s aggregates carry a version. When you load seat F-14 you get its version; when you save, Relay checks the version still matches. If someone else changed it in between, your write is rejected with a ConcurrencyConflict — loudly, automatically, before any damage is done.

// Both requests load F-14 at version 7 and try to sell it.
// First write: succeeds, F-14 is now version 8.
// Second write: version is no longer 7 -> ConcurrencyConflictException.
// Customer B is gently told "that seat just went" — not handed a duplicate.

Now the second buyer gets an honest “sorry, that one just sold” instead of a fake confirmation and a real argument at the door. For the truly contested resources — the last seat, the limited drop — Relay also offers a pessimistic per-aggregate lock: the second buyer simply waits a beat for the first to finish, then sees the truth. Either way, the seat can only be sold once, and the framework enforces it on every path, including the one you write on a Friday.

What it costs you to ignore this

  • You sell things you don’t have. Double-booked seats, oversold inventory, two people promised the same thing.
  • The failure is invisible until it’s a person. Nothing alerts; you find out when a customer is standing in front of someone in their seat.
  • “Fix it in support” doesn’t scale. Every race becomes a manual refund and an apology, and the apologies don’t refund your reputation.
  • The bug hides in correct-looking code. Code review won’t catch it, because the logic isn’t wrong — the assumption is.