Design an Online Auction: Consistent Bidding Under Last-Second Rushes

Four capabilities define the product. A seller creates a listing with a starting price and an end time, which fixes the rules of that auction up front. A buyer places a bid, and the system only accepts it when it beats the current top amount; anything else is turned away. Viewers see the current price move without refreshing, which is what makes an auction feel alive and pushes people to bid again.

Finally, once the deadline passes, bidding stops and the top bidder is declared the winner. Payments, shipping, search and recommendations are real parts of a marketplace, but they hang off the auction-closed moment and can be designed separately. Keeping them out of scope lets the discussion focus on bidding, live updates and closing.

Consistency comes first. Two competing bids must never both be recorded as the winner, and an accepted bid must never vanish. If a buyer is told "you are the highest bidder" and later finds that was false, trust in the platform collapses. This requirement shapes the entire data path for bids.

Live updates should reach watchers within about a second, since a stale price leads people to bid amounts that are already too low. Hot auctions need special care: sniping, where buyers wait for the last moments to bid, concentrates traffic into a tiny window on a single listing. And the ending must be precise and happen once. A bid that lands after the deadline must be rejected, and the close-and-announce step must not run twice and crown two different winners.

Assume about 10 million auctions are open at any moment. If the platform receives roughly 100 million bids a day, dividing by 86,400 seconds gives around 1,160 bids per second on average. A single relational database cluster handles that comfortably. Assume also about 5 million people are watching auctions live, each holding an open connection for price updates, which sizes the push tier.

The number that matters most is the hot case. One popular listing might see around 1,000 bids per second in its final minute, and every one of them targets the same auction row. So the estimate points away from sharding for total volume and toward handling contention on a single record without either losing bids or stalling under lock waits.

Four entities carry the model: an auction, the item it sells, the individual bids placed on it, and users acting as buyers or sellers. A seller calls POST /auctions with the item, a starting price and ends_at, and receives an auction ID. Reading the listing through GET /auctions/{id} returns its status, deadline and leading amount.

Bidding uses POST /auctions/{id}/bids with an amount and an idempotency_key. The key matters because nervous bidders double click and mobile networks retry; the server stores the key with the bid so a repeat returns the original result instead of creating a second bid. A successful bid returns 201, and a bid beaten by someone else returns 409 so the client can show an outbid message. Live prices come from GET /auctions/{id}/events, a server-sent events stream that pushes each new accepted bid.

Requests enter through an API gateway that authenticates users and routes calls. Listing creation and reads go to an auction service, which stores items, start prices and end times in a Postgres auction database. Bids go to a separate bid service whose single job is to validate a bid against the current top amount and write it atomically. Splitting the two lets the bid path stay small and heavily tested.

Once a bid is accepted it is published as an event to Kafka. A tier of live update servers consumes those events and pushes the new price over SSE to the browsers watching that auction. Using a log in the middle decouples writing a bid from notifying viewers, so a slow push server never delays a bid.

An auction closer runs independently. It triggers at each listing's ends_at, marks the auction closed in the database and records the winner. Keeping closing separate from bidding means neither path needs to know about the other's timing.

The naive approach reads the current top bid, compares in application code, and then writes. Two requests can read the same old price within milliseconds, both conclude they are winning, and both write. One update silently overwrites the other. Locking the row with SELECT ... FOR UPDATE is correct, but on a hot listing hundreds of requests line up behind the lock, each holding a database connection, and the pool drains.

The chosen approach moves the comparison into the write: UPDATE auctions SET highest = :bid WHERE id = :id AND highest < :bid AND status = open. The database evaluates the condition and applies the change as one atomic statement. If one row changed, the bid won and the bid record is inserted in the same transaction. If zero rows changed, a higher bid already landed and the user is told they were outbid. No lock is held beyond the statement itself.

For an extreme listing, all its bids can additionally be routed through one queue partition keyed by auction ID, giving a single ordered writer. That trades some throughput for perfect ordering and is reserved for the rare hottest items.

Getting a bid onto every watcher's screen starts with a reliable event. When the bid service commits a bid, it also inserts a row into an outbox table inside the same transaction. A relay process reads the outbox and publishes to Kafka, keyed by auction ID. If the service crashes after commit, the outbox row is still there, so no accepted bid goes unannounced.

At roughly 1,160 events per second across the whole platform, the stream is small enough that every live update server can consume all of it. Each server holds an in-memory map from auction ID to its open SSE connections. For each event it looks up the auction; if nobody on that server is watching, the event is dropped, otherwise the new price is written to every matching connection and appears in well under a second.

SSE suits this flow because data only travels from server to browser. It runs over ordinary HTTP, works through most proxies, and browsers reconnect automatically. Placing a bid remains a normal POST, so a bidirectional WebSocket channel adds complexity without benefit.

Closing correctly begins with where the truth lives. The ends_at time and the status field sit on the auction row in the database, not in a timer inside some server's memory that disappears on restart. The bid statement itself also checks that the current time is before ends_at. That makes late bids impossible even if the closing job runs a few seconds behind, because the rule is enforced at the moment of writing.

A scheduler such as a delay queue fires a close job at each end time. If the worker handling it crashes, the job is not acknowledged, so it becomes visible again and a different worker retries it. The close is idempotent: it sets status to closed only where status is still open, so a duplicate run changes zero rows and does nothing. After a successful close, an auction-closed event goes out to notify the winner and seller and to kick off the payment flow handled by other systems.

Optimistic concurrency avoids lock queues, but the cost is that losing bidders must receive a clear outbid response and possibly retry with a higher amount. Choosing SSE over WebSockets gives a simple one-way push over plain HTTP, which fits because viewers never need to send messages back over that channel.

The design is deliberately split in its consistency: bids are strongly consistent, while the price displayed to viewers can trail by a second. That is acceptable because the database, not the screen, decides the winner. For the very hottest listings a single partition writer guarantees ordering but caps that one auction's throughput. The overall recipe is atomic conditional writes for bids, pushed events for viewers, and a single idempotent close at the deadline.