Design an Online Auction System (eBay / Real-Time Bidding)
Design an Online Auction System (eBay / Real-Time Bidding)
Online auction systems allow sellers to list rare items for timed bidding. As the countdown clock ticks toward zero, hundreds of eager buyers engage in "bid sniping" (submitting bids in the final seconds), demanding atomic concurrency control and instant broadcast updates.
1. System Requirements
Functional Requirements
- Create Listings: Sellers specify item details, reserve price, starting bid, and auction end timestamp.
- Place Bids: Buyers place bids higher than the current highest bid + minimum increment.
- Real-time Price Broadcast: All users viewing the auction see the updated leading bid within $< 200\text{ms}$.
- Sniping Protection / Soft Close: If a bid is submitted in the final 2 minutes, auto-extend the auction by 2 minutes to prevent bot exploitation.
- Auction Settlement: When the timer expires, the highest bidder wins and enters the payment checkout flow.
Non-Functional Requirements
- Strict Bid Consistency: Exactly one leading bid at any price point; race conditions must never record overlapping winners.
- Sub-second Latency: Bid placement must acknowledge in $< 50\text{ms}$.
- High Availability: 99.99% availability during high-traffic auction closes.
2. Concurrency & Bid Placement Engine
Handling 10,000 users bidding simultaneously in the last second requires memory-speed atomic transactions:
-- Redis Lua Script: Atomic Bid Verification & Update
local auction_id = KEYS[1]
local new_bid = tonumber(ARGV[1])
local user_id = ARGV[2]
local current_bid = tonumber(redis.call('HGET', auction_id, 'highest_bid') or '0')
local end_time = tonumber(redis.call('HGET', auction_id, 'end_time'))
local now = tonumber(ARGV[3])
if now > end_time then
return {err = "AUCTION_CLOSED"}
end
if new_bid > current_bid then
redis.call('HSET', auction_id, 'highest_bid', new_bid, 'highest_bidder', user_id)
-- Extend time if bid placed in last 2 minutes (120 seconds)
if (end_time - now) < 120 then
redis.call('HSET', auction_id, 'end_time', end_time + 120)
end
return {ok = "BID_ACCEPTED"}
else
return {err = "OUTBID"}
endKey Architecture Trade-Offs & Decision Matrix
| Decision Factor | Choice A | Choice B | Selected Architectural Rationale |
|---|---|---|---|
| Communication Protocol | REST over HTTP/2 | WebSockets / gRPC | Use REST for stateless CRUD APIs; use WebSockets for low-latency bidirectional streaming. |
| State Management | Centralized Distributed Store | Local Memory with Sticky Sessions | Centralized Redis / Database state allows seamless container auto-scaling and zero-downtime rolling deploys. |
| Concurrency Control | Optimistic Locking (version column) | Pessimistic Locking (SELECT FOR UPDATE) | Optimistic locking delivers superior throughput for low-conflict consumer operations. |
Related Topics
Expand your knowledge by learning about adjacent concepts in system design.
Design a Distributed Caching System (Redis Architecture)
Comprehensive architecture guide for designing production-grade Redis distributed caching clusters: master-replica replication, Redis Sentinel, Redis Cluster sharding, and memory eviction.
Design a URL Shortener (TinyURL / Bitly Architecture)
Design a scalable URL shortening service capable of handling billions of redirects: Base62 encoding, distributed ID generation, database indexing, and 301 vs 302 redirect trade-offs.
Dealing with High Concurrency & Contention
Strategies for mitigating hot keys, race conditions, and lock contention: Optimistic Concurrency Control, Pessimistic Locking, Distributed Redlock, and Write Coalescing.
Cheat Sheet Utility
View and print a concise system design reference card.