Design Online Auction Platform

Meta's "Design Online Auction Platform" interview question focuses on building a scalable system for real-time bidding, emphasizing concurrency control, backend services, web-scale architecture, system design principles, and real-time updates.[1][3]

Problem Statement

Design an online auction platform supporting English-style auctions (open outcry with incremental bids) at web scale. It must handle global users on desktop/mobile, many concurrent auctions, real-time bid updates, low-latency bidding (<100ms), and features like auction creation, bidding, viewing current bids, and auction closure with winner determination. Key challenges include bid consistency under high contention, real-time fanout to watchers, sharding auctions, fraud detection, and payment/escrow flows. Assume single currency (e.g., USD) and UTC times; scale to millions of daily auctions and tens of millions of bids.[2][3][9][1]

Functional Requirements

• Users create auctions specifying item details, starting bid, bid increment (e.g., $1 minimum), duration (e.g., 1-7 days), and end time.
• Users place bids higher than current highest + increment; system validates and updates in real-time.
• Viewers see live auction state: current highest bid, bidder, time remaining, bid history.
• At end time, declare winner, notify parties, trigger payment.
• Out-of-scope initially: search/filtering, categories, user profiles, item photos.[3][2]

Non-Functional Requirements & Constraints

• Scale: 10M concurrent auctions daily, 100M+ bids/day, 1K bids/sec peak per popular auction.[9][2]
• Latency: Bid submission/acceptance <100ms; real-time updates to 1K+ watchers <1s.[5][1]
• Consistency: Strong for bids (no double-spending, out-of-order bids); causal ordering across replicas.[5]
• Availability: 99.99%; fault-tolerant with no single point of failure.
• Concurrency: Handle bid races via optimistic locking, distributed locks, or DB transactions.[1][2]
• Data: Auctions/bids durable; retain history 1+ year; peak 1TB+ data.[3]