Design an online auction system
Company: Meta
Role: Software Engineer
Category: System Design
Difficulty: medium
Interview Round: Onsite
##### 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.
Overview: A Meta software engineer onsite system design question: build an eBay-style online auction platform supporting proxy bidding, reserve prices, buy-it-now and soft close at 500k concurrent auctions and 5M watchers with p99 bid-to-UI latency under 200 ms. The answer covers APIs, data model, the proxy-bid pricing algorithm, single-writer-per-auction consistency, idempotent bid placement, real-time push trade-offs (polling vs long polling vs SSE vs WebSockets), sharding, finalization and recovery. It also covers anti-sniping, fraud, escrow payments, auditability and capacity estimation.