Design an online auction system

Question

Design a scalable, highly available online auction system (eBay-style) where sellers list items and buyers bid on them in real time.

Functional scope

• Users register, authenticate, and browse or search active auctions.
• Sellers create auctions with item details, start/end time, a starting price, an optional reserve price, a bid increment scheme, and an optional buy-it-now price.
• Buyers place bids while an auction is live and see the current highest bid and the bid history.
• Watchers receive near-real-time updates when the leading bid changes, when the end time is extended, and when the auction closes.
• The system supports proxy bidding — a bidder submits a maximum, and the system raises their standing bid in increments only as far as needed to stay in the lead — and soft close: a bid arriving within X seconds of the end extends the auction by Y seconds.
• At auction end the winner is determined unambiguously and an order is created.

Scale and targets

• Millions of registered users; up to 500k concurrent live auctions and ~5M concurrent watchers.
• Bids spike hard in the final seconds of popular auctions; hundreds of thousands of users may watch a single hot auction.
• p99 bid-to-UI latency under 200 ms.

Address the following

1. Functional APIs — CreateAuction, GetAuction, PlaceBid, SubscribeAuctionEvents, CloseAuction: request/response shapes and error cases.
2. Data model — Users, Items, Auctions, Bids, Watchlists, Payments, plus the indexes the read paths need.
3. High-level architecture — services, data stores, caches, message bus, and the real-time push tier.
4. Bid pricing algorithm — how reserve price, tiered increments, proxy maximums, and buy-it-now interact to produce the displayed current price.
5. Consistency and winning-bid determination — how you guarantee no lost winning bid and no two winners, especially in the last seconds.
6. Idempotency and concurrency control for PlaceBid — row locks vs optimistic versioning vs a single-writer-per-auction partitioned stream, and the trade-offs of each.
7. Real-time push — compare polling, long polling, Server-Sent Events, and WebSockets, and justify your choice. Cover event ordering, sequence numbers, and reconnect/backfill.
8. Sharding and partitioning (e.g. by auctionId), ordering of bids across partitions, and hot-auction mitigation.
9. Auction finalization — scheduler/timer design, idempotent close, order creation, failure recovery, and replay after a shard leader dies.
10. Anti-sniping, network delays, retries, and clock skew — which clock is authoritative, and how late or retried bids are treated.
11. Fraud and abuse — shill bidding, velocity limits, sellers bidding on their own items.
12. Payment and escrow flow for the winner, including failed capture and second-chance offers.
13. Security, privacy, and auditability — authn/authz, encryption, an immutable bid log, and a tamper-evident audit trail.
14. A rough QPS/throughput estimation approach, and the key metrics and alerts you would put on this system.