Design an online auction (eBay)

Two bids arriving within the same millisecond must not both be told they lead. The cleanest way to reason about it is that each auction is a tiny state machine that must apply bids one at a time. Two practical implementations exist. Option one, optimistic concurrency on the row: every bid reads the row, computes the new state with the proxy rule, and writes with a version check. Conflicts retry. This works well up to a few hundred bids/s per auction; beyond that, retries pile up. Option two, a single writer per auction: route all bids for an auction to one owner (partition bids by auction_id in Kafka or use a sharded actor system like Akka or Orleans). The owner keeps the auction state in memory, applies bids sequentially at tens of thousands per second, persists each decision to the database or a replicated log before replying, and is the only writer. Failover moves ownership via leases, and the new owner reloads from the database. Either way, the bid log is append-only for audit, and money-like values are integers. Mention that proxy bidding is not only a feature: because most competing bids are resolved by comparing maxima, it reduces the number of round-trips that users make, which reduces load near close.

Most bids arrive in the final minute, many in the last few seconds (sniping), sometimes from tools. Three rules keep it fair and correct. First, the server clock decides: a bid is valid only if its accept time at the bid service is before ends_at, and the close workflow flips status before deciding the winner, so no bid can sneak in after. Use one time source (NTP-synced servers, and compare to the auction's ends_at in the same database transaction when possible). Clients show a countdown from the server_time returned in responses, not their own clock. Second, decide on hard close vs soft close. eBay uses a hard end time and relies on proxy bidding to make sniping less useful: if your maximum was honest, a sniper must beat it anyway. Many other auction sites use soft close: a bid in the last 2 minutes extends the end time by 2 minutes, which removes the advantage of sniping but makes end times unpredictable. Third, prepare capacity: auctions ending at popular times create bursts, so pre-warm bid service owners for auctions ending in the next 10 minutes and keep the close timers spread with a jitter-free, durable scheduler.

Bid decisions need strong consistency; showing them to watchers does not. Separate the two. After a bid is committed, an event goes to Kafka. Fan-out workers publish to Redis pub/sub (or a dedicated pub/sub like NATS) on a channel per auction. WebSocket gateway nodes subscribe only to channels their clients care about, so a node with 50k connections holding 2k distinct auctions has 2k subscriptions. For a hot auction with 200k watchers and 2k bids/s, sending every update to every watcher is 400M messages/s, which is wasteful. Instead, coalesce: the gateway sends at most 4-5 updates per second per auction with the latest state. Each event carries the version so clients drop older ones. If a client reconnects, it fetches the current state over HTTP first, then subscribes. Outbid notifications (push/email) are a separate, slower path with deduplication so a user outbid ten times in a minute gets one message.

Row CAS is simple, uses a normal SQL database and survives restarts naturally, but retries explode under 1k+ bids/s on one auction. A single-writer actor handles hot auctions easily but adds routing, leases and failover logic. A pragmatic design starts with CAS and routes known-hot auctions (many watchers) to an in-memory owner.

Hard close gives predictable end times and matches eBay; proxy bidding limits the harm of sniping. Soft close (time extension) is fairer for high-value items but makes scheduling and user expectations harder. Make it a per-category setting.

Bids go to the primary with CAS; pages and watchers read from Redis and may lag a few hundred milliseconds. The bid response always comes from the primary, so the bidder's own result is never stale.

The leader's maximum must never be shown. Keep leader_max and second_max only in the auction row and bid log with access controls; the public API returns only current_price.

All bids hit one row or one owner. CAS retries rise above a few hundred bids/s; move the auction to an in-memory single writer and reject clearly-too-low bids early using the cached price, before touching the primary.

Close timers fire in bursts. Run the timer service sharded by auction_id with enough workers; closing is a small transaction, so 500/s is fine for a sharded SQL tier.

Millions of connections need many gateway nodes. Coalesce updates per auction, subscribe per node not per connection, and shed non-critical updates (bid count) before price updates under load.

The client retries with the same Idempotency-Key; the bid service finds the stored result for that key and returns it, so the bid is not applied twice.

Its lease expires within a few seconds; a new owner loads the state from the database (every accepted bid was persisted before replying). Bids during the gap fail fast and clients retry. If the gap crosses ends_at, the close uses the persisted state, so no accepted bid is lost.

Bids are still rejected after ends_at because the bid path checks the time itself. The close workflow running late only delays notifications, not the outcome.