Design an Online Bidding Service (eBay)

The prompt sounds like a shopping cart with a timer: "Design the auction system behind eBay. A seller lists an item with a starting price and an end time. Buyers bid until the clock runs out, and the highest bid at close wins. Two things are non-negotiable: the winner must always be the person who genuinely bid the most, and a hot auction must not fall over in its last ten seconds."

Most candidates hear "bid" and model a price. A buyer clicks, the price goes up, the last click wins. It is the right instinct applied to the wrong noun. On eBay a bid is not a price. It is a maximum, held in secret by the system, which bids on your behalf one increment at a time against everyone else's maximum. A candidate who notices that in the first ten minutes builds a system where the displayed price is derived from two hidden numbers, where the winner is provably the highest maximum, and where an honest early bidder beats a last-second sniper at the same amount. The other candidate builds a system that cannot do any of those things, and then spends the hour defending it.

The second surprise arrives with the arithmetic. "A hot auction must not fall over" sounds like a write-throughput problem, so that is what candidates design for. Then you do the estimation and discover that the hottest auction of the year takes 200 bids a second on one database row, which a two-millisecond transaction handles with room to spare, while the same auction's 50,000 watchers would need 10 million push messages a second to see every price change. The hard problem was never the writes. It was the fan-out and the clock, and you could only have learned that from the napkin.

The Trap Built Into a Familiar Shape

Two failures show up in this question again and again:

• The Price Clicker: models a bid as the number on the screen, so every bid is a price and the highest price wins. It works, and it is not how eBay works. It cannot proxy-bid, it rewards whoever clicks last, and it has no answer for two bids of the same amount. Signal: modelled the user interface instead of the market mechanism.
• The Consensus Cathedral: hears "the winner must always be correct" and reaches for Paxos, Spanner, a global lock service, or a blockchain, for a problem whose entire contention is one row receiving 200 writes a second. Signal: never did the arithmetic, so never discovered that one row lock already gives every guarantee the prompt asked for.

The passing performance notices three things early: a bid is a maximum, an auction is a single serialisation point that fits inside one database transaction, and the thing that scales badly is not the bidding but the fan-out to people watching and the burst of closes at seven in the evening.