Design an Auction or Bidding System (eBay-like)

Hard45 min
1 / 30
understanding•10 min read

Problem Statement: A Real-Time Competitive Bidding Platform

Frames the auction system as a concurrency-critical, fairness-sensitive marketplace—not a simple CRUD app.

Problem Statement

Design an online auction marketplace where sellers list items with start/end times, buyers place bids (including maximum proxy bids), the system automatically determines the current winning bid using bid increments, handles last-second sniping surges, notifies outbid users in real time, and resolves the final winner atomically at auction close.

This is not a standard e-commerce catalog problem. The defining challenge is competitive concurrency under time pressure: multiple bidders race against each other and against the auction clock, and the system must guarantee fairness (first valid bid wins), atomicity (no two winners), and transparency (every participant sees the correct current price).

Why This Problem Is Distinctive

A product catalog can tolerate eventual consistency for seconds. An auction cannot. If two bids arrive within the same millisecond, the system must deterministically order them. If a bid arrives at the exact moment the auction closes, the system must define whether it counts. If a proxy bid engine auto-increments a bid while a human submits a competing bid simultaneously, the resolution must be race-free.

The problem requires: item listing with start/end times, real-time proxy bidding (max auto-bid), final price resolution at auction close, and notifications for outbid or winning status. Non-functional requirements include high concurrency near closing time, data integrity against fraudulent bids, scalable event processing for watchers, and potentially global multi-currency support.

The Three Hard Problems

  1. Bid Ordering and Fairness: When two bids arrive simultaneously, who wins? The system needs a total order over bids per auction, typically a monotonically increasing sequence number assigned by a single-writer per auction partition.
  1. Proxy Bidding Engine: eBay's proxy system lets a bidder set a maximum. The system then auto-bids the minimum increment above the current price until the max is reached. This engine must execute atomically with each incoming bid—no window where the displayed price is inconsistent with the true highest proxy.
  1. Atomic Auction Close: At the deadline, the system must freeze the auction, determine the winner, calculate the final price (second-price + increment), notify all parties, and prevent any late bids—all within a bounded time window even under peak load.

Public Operating Baseline

eBay reported approximately 134 million active buyers and 1.5 billion live listings as of 2023 earnings reports. Their engineering blog describes handling peak bid rates during major auction events. StockX processes over 100,000 bids and asks daily across sneaker, streetwear, and collectible categories using a continuous double-auction model. Bring a Trailer implements a 2-minute anti-sniping extension rule for automotive auctions.

For capacity planning, this answer explicitly assumes a mature platform with 50 million registered users, 5 million concurrent active users at peak, 100,000 simultaneous live auctions, and 200 million bids per day. Unless tied to a citation, every number is a stated design assumption.

The Four Architectural Planes

  1. Bidding Plane: Bid intake, validation, proxy engine execution, bid ordering, and price determination.
  2. Auction Lifecycle Plane: Listing creation, scheduling, state transitions (pending → live → closing → closed → settled), and anti-sniping extensions.
  3. Notification Plane: Real-time outbid alerts, watcher updates, winner notifications, and seller confirmations.
  4. Trust Plane: Fraud detection, bid retraction policies, seller verification, dispute resolution, and audit trails.

Key Highlights

  • •The core challenge is deterministic bid ordering under concurrent access—not CRUD throughput.
  • •Proxy bidding requires atomic read-modify-write per auction: no window for price inconsistency.
  • •Auction close is a distributed coordination problem: freeze, resolve, notify, and reject late bids atomically.
  • •Public figures (eBay 134M buyers, StockX 100K+ daily bids) provide context; uncited numbers are explicit assumptions.
  • •Four planes: Bidding, Auction Lifecycle, Notification, and Trust—each with different consistency requirements.
Lead With Fairness
State in the first two minutes that bid ordering must be deterministic and race-free. This immediately distinguishes an auction design from a generic marketplace CRUD app.
Do Not Treat Bids as Simple Inserts
A design where each bid is just an INSERT with no ordering guarantee or proxy resolution will fail under concurrent access. The proxy engine must execute atomically with every incoming bid.

Section Rescue Kit

Buzzwords to use:

Second-Price AuctionAnti-Sniping Extension

Safe statements:

  • "I will separate bid correctness from notification delivery: the former must be synchronous and atomic, while the latter can be eventually consistent."
  • "Before selecting databases, let me define which operations require single-writer ordering per auction."
Design an Auction or Bidding System (eBay-like) - System Design | WinJob | WinJob