Design an Online Auction

Run 50 million live eBay-style auctions: order every bid strictly per auction, push the price to watchers live, and close each auction exactly once.

Last updated 2026-10-26. Difficulty: hard. Patterns: contention, compare-and-set, durable-timers, real-time, bidding. Reported at eBay, Amazon, Meta, Google, Microsoft, Shopify.

Functional requirements

• List an item for auction. Start price, an optional hidden reserve, a duration (1 to 10 days) or an explicit end time, and the close policy. The terms freeze at the first bid, because bidders relied on them.
• Bid with a maximum (proxy bid). The bidder states the most they will pay and the system bids for them one increment at a time, keeping the maximum secret. The visible price is the second-highest maximum plus one increment, capped at the highest.
• A definite answer to every bid. Leading, outbid by an existing maximum, or rejected (too low, auction ended). Each answer reflects every bid accepted before it, so two bidders are never both told they lead.
• Watch the price live. Anyone with the item open sees the price, bid count and time left update within a second without refreshing. The live view is a hint; the bid response is the truth.
• Close on time, exactly once. At end_at the auction stops taking bids and closes once, even if the close runs twice. With soft close, a bid in the final 2 minutes moves the end to 2 minutes after that bid.
• Charge the winner and settle. If the reserve is met, the winner is charged the final price on the saved payment method, with retries on failure and a second-chance offer to the runner-up as the fallback.
• Search and browse listings. Keyword, category, filters and sorts such as "ending soonest". A few seconds of staleness is fine, because nothing is decided from a search result.
• Notifications. Outbid, ending soon on watched items, won, lost and sold. At-least-once and deduplicated, and never on the bid path.
• Out of scope. Fixed-price Buy It Now checkout, shipping, ratings and feedback, seller fees and payouts beyond handing off to the payment system, photo hosting, and shill-bidding detection beyond keeping the complete bid log it needs.

Non-functional requirements

• One order of bids per auction (linearisable per auction). Every bid on an auction is applied in a single sequence and its answer reflects all earlier ones. This drives the hardest tradeoff in the design: strict serialisation per auction, at exactly the moment contention peaks.
• Bid latency (p99 < 200 ms). In the final seconds a slow answer is a lost auction, and a bidder who waits retries, doubling the load on the hottest row. Measured separately for bids in the last minute.
• Live price freshness (p95 < 1 s). Watchers of a hot auction may skip intermediate prices, but never see an older price after a newer one.
• Close correctness (once, within ~1 s of end_at). A double close can create two orders or two charges; a late close delays the winner and the seller. Bids after end_at are refused whatever the timers do.
• Availability of bidding (99.99 %). An outage in the last minutes of an auction cannot be fixed afterwards without someone feeling cheated. Shed search and live updates first, never bid acceptance.
• Scale and skew (50 M live · 2.3 k bids/s avg). Modest in aggregate. The problem is skew: a hot auction takes 200 bids a second in its last 10 seconds while millions of others take none.
• Fair and auditable deadlines (server clock decides). Whether a bid beat the end is decided by the shard primary at commit, never by the client. Every bid, accepted or rejected, is kept with its server time for disputes.
• Search freshness (p95 < 5 s). Listings and prices reach search through the change stream. Eventual consistency is fine there because no bid is decided by the index.

Back-of-envelope estimates

• Bids per second: ~2.3 k/s avg · ~12 k/s peak. 50 M live auctions ÷ a 5-day average life = 10 M auctions ending a day; × ~20 bids each = 200 M bids/day ÷ 86 400 ≈ 2.3 k/s. Evening peaks run ~5× that: ~12 k/s. Spread over millions of auctions, this is a modest write load.
• Auctions closing per second: ~116/s avg · ~600/s peak. 10 M closes a day ÷ 86 400 ≈ 116/s, peaking ~5× in the evening: ~600/s. Each close is one guarded transaction and one payment, so the close path is small; the hard part is that 50 M pending deadlines must each fire once and on time.
• Hot auction, final seconds: ~200 bids/s on one row. A hot auction takes 5 000 bids in its final minute, about 40 % of them in the last 10 seconds: 2 000 ÷ 10 = 200 bids/s. A serialised commit with a synchronous replica takes ~2–3 ms, so one row tops out near 300–500 commits a second. Close enough that optimistic retries from many writers would collapse it.
• Fan-out for one hot auction: ~10 M msg/s naive · ~200 k/s coalesced. 50 k live watchers × 200 price changes a second = 10 M messages/s if every change is pushed. Coalescing to the latest state every 250 ms (4/s) gives 50 k × 4 = 200 k/s, spread over the push servers. Coalescing, not bigger servers, is what makes the hot auction affordable.
• Live connections: ~5 M · ~100 push servers. Assume 5 M item pages open at peak, each holding one Server-Sent Events connection. At ~50 k mostly idle connections per server that is 100 push servers, plus headroom for a reconnect storm during a deploy.
• Bid storage: ~30 GB/day · ~11 TB/yr. 200 M bids a day × ~150 B (auction id, bidder, maximum, price after, server time, outcome, client bid id) = 30 GB/day ≈ 11 TB/year. Kept for audit and disputes, partitioned by auction id so every question about one auction stays on one shard.
• Auction store shards: ~6 needed · run 8. Peak 12 k bid transactions/s, each an insert plus one conditional update. At a conservative ~2 k such transactions a second per shard primary that is 6; run 8 for headroom. Live auction rows are 50 M × ~1 KB = 50 GB, so the working set fits in memory: storage is not what shards this store, isolating write load is.
• Search index: ~100 GB · ~2.4 k changes/s. 50 M live listings × ~2 KB of indexed fields (title, category, attributes, price, bid count, end time) = 100 GB before replicas. Changes arrive at the bid rate plus ~116/s new listings, ~2.4 k/s; coalescing price updates per listing to one every few seconds cuts index writes well below that.

Components

• Buyer / seller app: Web and mobile clients for listing, searching, watching and bidding. Generates a client bid id per bid attempt and reuses it on retry, keeps the highest auction version it has shown and ignores anything older, and draws the countdown from server time sent with each snapshot rather than the device clock.
• API gateway (auth · rate limits · routing): Authenticates, rate-limits bids per bidder per auction, and routes each bid by consistent hashing on auction id to the bid service instance that owns that auction. Serves item-page snapshots from the live state cache, so page views never reach the auction store.
• Bid service (owner per auction · proxy rules): Accepts or rejects bids. Each auction has one owning instance that queues its bids, applies the proxy rules in arrival order against the last committed state, and writes with a version check. Routing makes conflicts rare and allows group commit for hot auctions; the version check on the row is what makes a lost bid impossible.
• Auction store (sharded SQL · by auction_id): The source of truth for every auction and bid: one row per auction (state, price, leader, top two maximums, end_at, version) and an append-only bids table, all on the auction's shard. The bid, the deadline check, any soft-close extension and the outbox event commit in one transaction, with the shard primary's clock deciding the deadline. A synchronous replica means an acknowledged bid survives failover.
• Auction events (Kafka · key = auction_id): Every committed change (bid accepted, extended, opened, closed) from the outbox or CDC on the store's log, partitioned by auction id so each auction's events stay in version order. Feeds live fan-out, notifications, settlement and the search indexer, each at its own pace. Carries prices, never maximums or reserves.
• Live fan-out (coalesce to ≤ 4/s per auction): Turns auction events into live updates: the first change after a quiet spell goes out at once, later ones within 250 ms are folded into one carrying the latest state, and closes and extensions flush immediately. Writes the snapshot with a version guard and publishes it on the auction's channel. Coalescing here, before the fan-out, is what makes a hot auction cost 4 messages a second instead of 200.
• Live state + pub/sub (Redis · snapshot + channel): Holds the latest public snapshot of each active auction (price, bid count, end_at, state, version) and a pub/sub channel per auction. Item pages and reconnecting clients read the snapshot; push gateways subscribe to the channels. It may drop messages, because every message is the whole latest state and the next one replaces it.
• Push gateway (SSE · ~50 k conns/server): Holds the long-lived Server-Sent Events connections for open item pages, about 5 M at peak across 100 servers. Subscribes to an auction's channel only while it has a local watcher and writes each update once per connection. Read-only by design: bids never travel over it.
• Notifications (push · email, deduped): Sends outbid, ending-soon, won, lost and sold messages from the event stream. Deduplicates on (user, auction, kind, version) because the stream is at-least-once, and collapses a burst of outbid notices during a bidding war into the latest one.
• Listing service (create · edit · search): Creates and edits listings, validating the start price, reserve, duration and close policy, and pins the increment table and soft-close window onto the auction row. Freezes the terms once the first bid lands. Serves search and browse queries from the search index, never from the auction store.
• Close sweeper (leased per shard): One per shard, holding a lease: every second it finds auctions past end_at (and scheduled ones past start_at) through an index and applies a conditional close or open. The auction row is the timer, so soft-close extensions need no rescheduling, and a duplicate or late sweep matches zero rows.
• Settlement service (order per auction · retries): Turns auction.closed into an order keyed by auction id, so a redelivered event cannot create a second one, and charges the winner's saved payment method with an idempotency key per attempt. Timeouts retry with the same key; declines go back to the winner and retry on a schedule, ending in a second-chance offer to the runner-up.
• Search indexer (CDC consumer): Consumes the change stream, builds a search document per listing without the reserve or any maximum, and bulk-upserts with the auction version as an external version, so a late change can never overwrite a newer one. Coalesces price updates per listing to one write every few seconds.
• Search index (OpenSearch / Elasticsearch): Full-text search, facets and sorts (ending soonest, price, newly listed) over ~50 M live listings, about 100 GB plus replicas. Seconds behind the store by design: results show prices as hints, and nothing anyone bids on is read from here.
• Payment provider (Stripe / Adyen): Charges the winner's saved card. Slow and occasionally ambiguous: a timeout says nothing about whether money moved, which is why every charge carries an idempotency key and an unknown outcome is retried with the same key, never re-issued with a new one.

User flows

1. A bidder places a maximum bid. The core write. One transaction on the auction row decides the outcome, the new price and the deadline together; everything after it is derived from the committed event.
   1. The bidder submits a maximum bid with a client bid id. The client bid id is a UUID generated once per bid attempt and reused on every retry, so a timeout in the final seconds can be retried without placing a second bid. The gateway authenticates, checks there is a payment method on file, and rate-limits per bidder per auction (5 bids a second), which is plenty for a human and stops one script hammering a row.
   2. The gateway routes the bid to the bid service instance that owns this auction. Consistent hashing on auction id over the bid service instances. The owner keeps a queue per auction and the state it last committed, so bids for one auction are applied one at a time in memory. Routing makes conflicts rare; it is not what makes them impossible.
   3. The owner computes the outcome from the leader, the top two maximums and the new bid. Proxy rules: below the price plus one increment is too low; above the highest maximum takes the lead at that maximum plus one increment; otherwise the leader holds and the price rises to this bid plus one increment. A too-low bid can be rejected right here from cached state: the price never goes down, so a bid too low for a stale state is too low for the real one.
   4. One transaction inserts the bid and updates the auction row only if the version and the deadline still hold. The WHERE clause carries version = 41, state = open and end_at > now() at the shard primary, so a concurrent writer, a close or the deadline passing all make it match zero rows. Zero rows means re-read and recompute, never a blind retry. The same statement extends end_at if the bid landed inside the soft-close window, and the outbox row commits with it.
   5. The bidder gets a definite answer with the new price, version and end time. Leading, outbid by an existing maximum, or rejected with the reason and the minimum next bid. The version lets the page ignore any older live update that arrives after it. Returning end_at matters because this very bid may have moved it.
   6. The committed change is published to the auction event stream, keyed by auction id. An outbox relay, or CDC on the database log, publishes bid.accepted only if the transaction committed, and keying by auction id keeps each auction's events in version order for every consumer. The event carries the price, bid count, masked leader and end_at, never a maximum.
   7. The previous leader is told they have been outbid. Push and email, deduplicated on (user, auction, version) because the stream is at-least-once. During a bidding war one bidder can be outbid ten times a minute, so outbid notices are collapsed to the latest per auction every few minutes. None of this is on the bid path: a slow email provider never delays a bid.
2. A watcher sees the price move live. The main read. A snapshot first, then a stream of versioned latest-state updates: the live view may skip prices but never goes backwards, and none of it touches the auction row.
   1. The item page loads the current snapshot of the auction. The snapshot comes from the live state cache, not the auction store, so 50 k people opening a hot auction add no load to its shard. It includes server_now, so the countdown runs on server time and a phone with a fast clock does not show the wrong time left.
   2. The page opens an event stream for this auction on a push gateway. Server-Sent Events: one-way, plain HTTP, with reconnect and Last-Event-ID built in. Bids go over ordinary HTTPS requests, so the push tier never handles a write. One gateway holds around 50 k mostly idle connections.
   3. The push gateway subscribes to the auction's channel if this is its first local watcher. Subscriptions are per gateway, not per watcher: 50 k watchers spread over 100 gateways are 100 subscriptions. The gateway keeps a local map from auction to connections and unsubscribes when the last one leaves.
   4. A bid commits; the fan-out service reads the event and decides whether to send now or coalesce. Leading edge: the first change after a quiet period goes out immediately, so a normal auction updates within a few hundred milliseconds of the commit. Further changes inside 250 ms are folded into one update with the latest state. Closes and end-time extensions are never held back.
   5. The fan-out service writes the new snapshot and publishes it on the auction's channel. One Lua script: set the snapshot only if the stored version is lower, then publish. A replayed or late event can never roll the snapshot back, and the snapshot and the message always agree.
   6. Each subscribed gateway forwards the update to its local watchers, who drop anything older than what they show. The message is serialised once per gateway and written to every local connection. A client keeps the highest version it has shown and ignores lower ones, which also covers its own bid response racing the stream.
   7. After a dropped connection, the client reconnects and reloads the snapshot if it missed versions. Pub/sub keeps no backlog to replay. That is fine because the stream carries a value, not a log: the client compares the snapshot version with its last one and jumps straight to the latest. Reconnects use jittered backoff, so a gateway restart does not become a stampede.
3. A hot auction's final ten seconds. The scale-breaking case: 200 bids a second on one row and 50 000 watchers. Serialise once and cheaply, and coalesce everything a human does not need.
   1. Bids arrive at 200 a second from thousands of bidders, all routed to the auction's owner. Per-bidder rate limits at the gateway keep one script from dominating the queue. The owner's queue for this auction is bounded at a few thousand bids; past that it sheds with retry-after, though at 200 a second it is nowhere near.
   2. The owner rejects bids that are already too low without touching the database. In a bidding war many bids arrive below the price plus one increment, because the price moved while the bidder was typing. Since the price never falls, the owner's cached state is enough to reject them, at microseconds each instead of a commit.
   3. The rest are applied in arrival order in memory and committed as one batch every few milliseconds. Group commit: drain up to 5 ms of queued bids, compute each outcome in order against the running state, then write all the bid rows and one auction update guarded by the starting version. One commit of about 3 ms carries the whole batch, so the row's ceiling rises from a few hundred commits a second to thousands of bids. Each bidder gets the answer computed for their own bid once the batch commits.
   4. Under soft close, every batch in the final two minutes pushes the end time out. The batch sets end_at to two minutes after its commit, so the auction keeps running while bids keep coming and the final-second spike never forms. Under hard close nothing extends: bids reaching the primary after end_at fail the condition and are told they were late, with the server time.
   5. The fan-out service folds hundreds of changes a second into four updates a second. Coalescing happens before the fan-out, so the publish rate for the hottest auction is the same as for a busy ordinary one. The new end time is part of the state, so watchers see the extended deadline in the next update.
   6. Every push gateway with watchers forwards each update to its share of the 50 000. 50 k watchers × 4 updates is 200 k messages a second across about 100 gateways, 2 k each: comfortable. Pushing every bid would have been 10 M a second for this one item.
   7. New viewers arriving from a shared link load the snapshot from the cache, not the auction store. A viral auction draws page loads at thousands a second. Served from the live state cache, and a CDN with a one-second TTL for signed-out viewers, they never reach the shard that is busy taking bids, which is the one place in the system where contention is allowed.
4. The auction closes and the winner pays. The failure path. The sweeper may run twice or race a last bid, the event may arrive twice, and the payment may time out; the auction still closes once and the winner pays once.
   1. The shard's close sweeper finds auctions whose end time has passed. One sweeper per shard holds a lease and runs this every second against an index on (state, end_at). The result is only a candidate list: an auction on it may have been extended by a bid that is committing right now.
   2. Each candidate is closed with a conditional update, together with an outbox event. The WHERE clause re-checks state and end_at at write time. If a bid holding the row lock commits an extension first, this update waits, re-evaluates against the committed row and matches zero rows, so the auction stays open until its new end. The event carries the winner, the final price and whether the reserve was met.
   3. A sweeper that lost its lease during a pause runs the same close, and matches zero rows. A lease handover after a GC pause or a network blip can leave two sweepers working one shard for a few seconds. The lease only avoids duplicated work; the conditional close is the fence that makes the duplicate harmless.
   4. Watchers see the auction end at once. A close is a state transition, so the fan-out service flushes it immediately instead of waiting out the coalescing window. Bid buttons disable on the event, but that is a courtesy: a bid already in flight is refused by the deadline check in its own transaction.
   5. Settlement consumes the closed event and creates the order, keyed by auction id. The outbox relay is at-least-once, so the same auction.closed can arrive twice. The order's primary key is the auction id, so the second insert does nothing. If the reserve was not met there is no order: the seller and the high bidder are told, and the seller may relist.
   6. Settlement charges the winner's saved payment method; the call times out. A timeout is an unknown outcome, not a failure. The attempt is recorded before the call, and the retry uses the same idempotency key, so if the first charge did go through the provider returns it instead of charging again.
   7. The retry returns the original successful charge, and the order is marked paid. The provider recognises the key and returns the first result. Had it been a decline, the order would move to payment_failed and the winner would be asked to update their card, with daily retries for three days before the seller can make a second-chance offer to the runner-up at their own maximum.
   8. The winner, the seller and the losing bidders are notified. Driven by the closed and paid events, deduplicated on (user, auction, kind). Losing bidders see the final price; their maximums stay secret even after the close, because a seller who learned them could use them against those bidders next time.
5. A listing goes live and becomes searchable. The asynchronous path. The seller writes once to the auction store; search learns about it, and about every later price, extension and close, from the change stream, seconds behind and without secret fields.
   1. The seller creates a listing with a start price, a reserve and a duration. Validation happens here: a reserve above the start price, a duration from the allowed set, and the increment table version and soft-close window pinned onto the auction so the rules cannot change mid-auction. Photos are uploaded separately to object storage and referenced by id.
   2. The listing service writes the listing and its auction row on the auction's shard. The auction id is generated first, so the shard is known before the write. The row starts at version 0 with no leader, the price at the start price and end_at from the start time plus the duration. That row is also the close timer, so nothing else needs scheduling.
   3. A listing scheduled to start later is opened by the shard sweeper at its start time. The same sweeper that closes auctions opens scheduled ones, on an index of (state, start_at). Opening is conditional on state = scheduled, so a seller cancelling at the same moment either wins or loses cleanly.
   4. The change is captured from the database log and published. CDC reads committed changes, so the index can neither learn about a listing that never committed nor miss one that did. The same stream later carries every price change, extension and close for this auction, in version order.
   5. The indexer builds the search document and upserts it, skipping anything older than what the index holds. The document holds title, category, attributes, current price, bid count, end_at and state, but never the reserve or any maximum. The auction version is the document's external version, so a replayed old change is rejected by the index itself. Price updates are coalesced per listing to one write every few seconds.
   6. A buyer searches a category sorted by ending soonest and sees the listing within seconds. Open auctions sorted by end_at, plus keywords and filters. Prices on the results page are a few seconds behind; the visible rows load live snapshots for their countdowns, and the item page always reads the live snapshot. Nothing anyone bids on comes from the index.

Deep dives

The theory behind it

• Optimistic vs pessimistic locking: Two ways to stop concurrent updates from overwriting each other: pessimistic locks with SELECT FOR UPDATE, optimistic concurrency with version numbers and compare-and-set, lost updates, deadlocks, retries, contention levels, HTTP ETags, and which to use for bookings, inventory, documents and counters.
• Delayed jobs, timers and distributed cron: Running work at a specific time across a cluster: cron at scale, delayed queues, time-bucketed tables, timing wheels, leader election and partitioned schedulers, exactly-once firing, time zones, missed runs and backfills.
• Real-time systems: WebSockets, SSE and push: Long polling vs Server-Sent Events vs WebSockets, connection servers and registries, pub/sub fan-out, presence, reconnection and resync, and scaling to millions of connections.

Related

• Design Slack
• Design AWS Step Functions
• Design a Recommendation System
• Design Post Search
• All 83 system design interview questions
• Run this question for a friend: the interviewer kit