Design an Online Auction

The ask

A seller lists one item with a starting price and an end time. A minimum step sets the smallest rise over the current price.

Buyers place bids during the open window. Each accepted bid becomes the new current price.

At the end time the highest accepted bid wins. The winner pays and the seller ships the item.

Bidders watch the current price live. A stale price invites bids that cannot win.

Estimate the scale

1,000,000 auctions run a day.

1,000,000 / 86,400 = 12 auctions per second.

Bids arrive at 100,000,000 a day.

100,000,000 / 86,400 = 1,157 bids per second.

A hot auction takes 1,000 bids in its final minute.

1,000 / 60 = about 17 bids per second on that one item.

API and data

The create operation takes the item, the starting price, the minimum step and the end time.

The bid operation names the auction and the amount. The response states accepted or rejected, with the current price either way.

An auction record holds the item, the seller, the current price, the leading bidder and the end time.

A bid record holds the bidder, the amount and the acceptance time. Accepted and rejected bids are both recorded.

High-level design

An auction service owns listings, bids and closings. Auctions are sharded by auction identity, so load spreads across servers.

Item pages are served from a cache holding the current price. Price updates refresh the cached page data at once.

A closing worker watches end times and settles finished auctions. Settlement hands the result to payment and messaging.

Deep dive: bidding on a hot item

Bidding on one auction is a contention problem. Every bid must be judged against the latest accepted bid.

One writer per auction accepts bids in arrival order. A bid wins only if it beats the current price by the minimum step.

A hot auction draws about 17 bids per second in its final minute. One writer orders that rate with ease.

A rejected bid returns the fresh current price. The bidder can raise a bid without guessing.

Every accepted bid is appended to the auction's bid log before the price moves. A crash replays the log and restores the exact price.

Closing and late bids

Server time decides the close, never a bidder's clock. A bid stamped after the end time is rejected as late.

A bid inside the final stretch extends the end time by a short fixed amount. Last-second sniping then gains nothing, since rivals always get a reply window.

The winner is the highest accepted bid in the log at the final end time. The log settles any dispute.

Trust and payment

Accounts linked to the seller are blocked from bidding on that seller's items. Planted bids that only push the price are a named abuse.

The winner's payment is held by the payment system until the item ships. A failed payment passes the win to the next highest bidder.

Bid histories are visible after closing, with bidder names hidden. Visible history deters planted bidding.

Evaluation and trade-offs

An online auction is a per-item ordering problem with a clock. One writer and one log per auction carry the design.

One writer caps one auction's bid rate and keeps its order exact. Sharding by auction keeps the overall rate high.

Closing extensions anger last-second bidders and protect honest ones. The fixed extension keeps the rule predictable.

Cached item pages scale reads and risk a stale price. Instant price refresh keeps the risk window tiny.

Auction scale