Design an Online Auction

A seller lists a vintage camera, starting at $50, ending Sunday at 20:00:00. All week a few people bid. In the last ten seconds, fifty people bid at once, each sure they are on top. When the clock hits 20:00:00, exactly one of them must have won, every watcher must have seen the same price, and a bid that arrived 40 milliseconds late must not count.

It looks like a simple CRUD app and hides three hard problems: many people writing one record at once, showing it live to everyone, and an exact deadline. The question means the kind of product eBay runs: timed auctions. The steps follow A Framework for Any Design. Try each "Your turn" box before you read on.

#Clarify the problem

• Functional: create an auction (item, starting price, increment, end time); place a bid; see the current highest bid update live; close the auction at its end time and tell the winner and seller; see the bid history.
• Non-functional: bids on one auction are strictly ordered and never conflict (strong consistency per auction); an accepted bid is durable; bids are rejected after the end time by an exact rule; new highs reach watchers within 1 second; the site stays up while a hot auction ends.
• Out of scope: payment and shipping, search and recommendations, fraud detection, buy-it-now and reserve prices.

#Estimate the scale

These are the scenario's givens. A day has 86,400 seconds.

• Live auctions: 1.5 million a day × 7 days ≈ 10 million open at any time.
• Bids: 1.5 million × 10 = 15 million a day ÷ 86,400 ≈ 170 a second. Endings cluster in the evening; assume a 10x peak, about 1,700 a second.
• Page reads: 100 views per bid gives about 17,000 reads a second: a job for caches and replicas.
• Storage: bids at 100 B: 1.5 GB a day, about 550 GB a year. Auctions at 2 KB: 3 GB a day, about 1.1 TB a year. Photos go in blob storage.
• The hot auction: 500 bids in its last 10 seconds is 50 bids a second, all on one row.

#Define the API

POST /auctions
  body: { "title": "...", "start_cents": 5000, "increment_cents": 500,
          "end_at": "2026-11-15T20:00:00Z" }
  201 { "auction_id": 812 }
 
GET  /auctions/{id}
  200 { "high_cents": 11000, "min_next_cents": 11500, "high_bidder": "an***",
        "seq": 36, "end_at": "...", "server_time": "2026-11-15T19:58:02.120Z" }
 
POST /auctions/{id}/bids
  body: { "bid_id": "b-1", "amount_cents": 12000 }
  201 { "status": "accepted", "seq": 37 }
  200 the same body again        a retry with the same bid_id
  409 { "status": "outbid", "min_next_cents": 12500 }
  410 { "status": "ended" }
 
GET  /auctions/{id}/live        text/event-stream
  event: high   data: { "seq": 37, "high_cents": 12000, "min_next_cents": 12500 }
  event: ended  data: { "winner": "ca***", "final_cents": 13000 }
 
GET  /auctions/{id}/bids?before_seq=37&limit=20     history, newest first

The decision worth arguing: the bid answers synchronously. You could queue bids and reply "received", but a bidder in the last ten seconds must know now whether to bid again. The path is one conditional write, so a direct answer is cheap.

bid_id is the bid's idempotency key. Without it, a retried $120 bid that already succeeded is checked against the new $125 minimum and comes back "outbid". server_time lets the countdown run on the server's clock.

#Model the data

auctions
  auction_id       BIGINT PRIMARY KEY
  seller_id        BIGINT
  title            VARCHAR(200)
  increment_cents  BIGINT
  end_at           TIMESTAMP
  status           VARCHAR(8)       -- open | closed
  high_cents       BIGINT NULL
  high_bidder_id   BIGINT NULL
  min_next_cents   BIGINT           -- starts at the starting price
  bid_count        INT              -- also the last bid's seq
  INDEX (status, end_at)            -- for the closer
 
bids
  auction_id   BIGINT
  seq          INT                  -- 1, 2, 3 ... per auction
  bid_id       VARCHAR(40)          -- from the client
  bidder_id    BIGINT
  amount_cents BIGINT
  placed_at    TIMESTAMP
  PRIMARY KEY (auction_id, seq)
  UNIQUE (auction_id, bid_id)

Access patterns: a conditional update of one auction plus one bid insert, together; reads of one auction and its history; and "open auctions past their end" for the closer. Every write touches one auction, so use a relational database partitioned by auction_id, bids beside their auction. Each bid is a single-partition transaction.

Keep every bid: "your bid was #37, at 19:59:58.100, for $120" settles disputes. Rejected attempts go to a separate log, off the hot path, for fraud checks.

#High-level design

Step through the last seconds of auction 812: a race, a retry, a live server failing, a late bid and the close.

#Deep dives

Interviewers push on four things: concurrent bids, the live price, the deadline, and the one auction everyone wants.

#Concurrent bids

Two bids arrive together. Each would read "high is $110" and write a new high. Every bid must be judged against the true current high.

WITH won AS (
  UPDATE auctions
     SET high_cents = 12000, high_bidder_id = :ana,
         min_next_cents = 12000 + increment_cents,
         bid_count = bid_count + 1
   WHERE auction_id = 812 AND status = 'open'
     AND end_at > now() AND 12000 >= min_next_cents
  RETURNING bid_count                        -- 37
)
INSERT INTO bids (auction_id, seq, bid_id, bidder_id, amount_cents, placed_at)
SELECT 812, bid_count, 'b-1', :ana, 12000, now() FROM won;
-- 1 row inserted: accepted as #37
-- 0 rows: read the auction to answer "outbid" or "ended"

The row lock is the serialisation point: the order bids get the lock is the order of seq. The lock is held until the commit, about 2 ms with the synchronous replica. It is the conditional update from ticket booking, which explains the isolation details. In PostgreSQL, now() is when the bid's transaction started, so a bid that arrived before the end but waited for the lock still counts. Before the statement, the service looks up the bid_id to answer retries; the unique key catches two copies that race. One auction needs 50 bids a second and the row allows about 500. At 5,000 a second on one item, move to one owner per auction and name the failover cost.

#Showing the highest bid live

Watchers only receive; bids go over POST. So use server-sent events: one-way, plain HTTP, automatic reconnect. A WebSocket would add a channel nobody uses. Fan-out works as in the stock trading app: a topic per auction, one subscription per live server. Two details matter here:

• Every update carries seq; the browser keeps the highest. Two auction servers can publish seq 37 and 38 a millisecond apart, and they can arrive in either order; so can a snapshot and a delayed message across a reconnect. Without the rule the screen would drop back to $120 in the final second.
• Send the latest state, at most every 250 ms. Each message is the whole current high, so skipping some is safe: 200,000 messages a second instead of 2.5 million. A bidder's own result comes from the POST, not the stream.

#Closing exactly at the end time

The tempting design is a timer that closes the auction at 20:00:00. Timers fire late and job queues fall seconds behind; if the close is what stops bidding, a slow closer lets late bids in.

So separate the jobs. The deadline is enforced in the bid's write: end_at > now(), judged by the database that owns the row. One clock judges every bid on that auction, so drifting app-server clocks cannot disagree. The closer only does bookkeeping, and can run seconds late with the same result.

Every second, the closer reads the (status, end_at) index and closes each auction past its end with SET status = 'closed' WHERE auction_id = 812 AND status = 'open' AND end_at <= now(). The last condition matters with a soft close, where a bid may have moved the end since the closer looked. Only the closer that changes 1 row emits "ended", so two closers never notify twice (see the job scheduler). If 10% of a day's 1.5 million auctions end in one hour, that is 150,000 ÷ 3,600 ≈ 42 closes a second: no load problem.

A soft close fits the same update: add end_at = GREATEST(end_at, now() + interval '2 minutes') to the SET. Either way, the server's receipt time decides: a bid sent at 19:59:59.900 that arrives at 20:00:00.100 is late.

#Scaling hot auctions

One auction cannot be split across machines, and need not be: 50 writes a second against a ceiling of about 500. Its real load is 50,000 viewers. Serve the page from a CDN and the current price from the live servers' memory, so the database sees bids, not viewers. Partitioning by auction_id usually puts two hot auctions on different partitions.

#Bottlenecks and failures

At 10x, 17,000 bids a second at peak, add database partitions; each auction still lives on one. 170,000 page reads a second is a cache and CDN problem. A single item at 10 times the hot auction, 500 bids a second, reaches the row's ceiling, which is when one owner per auction earns its complexity.

#What a strong answer sounds like

#Follow-up questions

#How would you support automatic bidding up to a maximum?

Store each bidder's secret maximum. On each new bid, the visible price becomes the second-highest maximum plus one increment, capped at the highest maximum; ties go to the earlier bid. The check reads several values, so lock the auction row, compute in code and write, all in one short transaction.

#How do you stop a seller bidding up their own item?

Reject the seller's own account in the write. Shill bids from other accounts need offline analysis of the bid history.

#Can a bidder retract a bid?

Mark the bid retracted and recompute the high from the remaining bids, in one transaction on the auction row. Allow it only well before the end, or retraction becomes a way to probe other bidders' limits.

#How do you show "you've been outbid" to someone who left the page?

The auction service publishes an "outbid" event for the previous high bidder, and the notification system sends a push or email, rate-limited so a bidding war does not send fifty.

#How would you run this in several regions?

Each auction has one home region where its bids are written; bidders elsewhere pay a round trip. Writing one auction in several regions would need consensus on every bid, which is slower.