System Design: eBay Marketplace

Requirements

Functional Requirements:

• Sellers list items as auction (timed bidding) or fixed-price (Buy It Now)
• Real-time bidding with proxy/automatic bidding support
• Buyer/seller trust via feedback scores and detailed seller ratings
• Product search with category filters, condition, price range, and location
• Secure checkout with buyer protection (money-back guarantee)
• Seller tools: bulk listing, repricing, and shipping label generation

Non-Functional Requirements:

• 133M active buyers, 1.9B live listings at any time
• Auction bid placement must be acknowledged within 200ms
• 99.99% availability for bidding and checkout paths
• Strong consistency for bid state — no two buyers can win the same auction
• Search index must reflect new listings within 30 seconds

Scale Estimation

With 133M active buyers and ~30M DAU, each browsing 20 pages: 600M page views/day = 6,944 views/sec. Search: 15M DAU × 4 searches = 60M searches/day = 694 QPS. Active auctions at any time: ~50M with bids happening in bursts near auction close. Bid rate: average 5M bids/day = 58 bids/sec, but spiking to 5,000 bids/sec in the final 10 seconds of popular auctions (auction sniping pattern). Listings: 1.9B items × 1KB metadata = 1.9TB; images average 8 per listing at 150KB = 2.3PB.

High-Level Architecture

eBay's architecture separates the listing/search read path from the bidding/transaction write path. The read path: CDN → Load Balancer → Search Gateway → a custom search engine (historically Cassini, now a Lucene-based distributed index) that indexes 1.9B listings across a cluster of 1,000+ search nodes. Product pages are assembled by a Page Composition Service that aggregates data from the Listing Service, Seller Service, Shipping Service, and Recommendation Service via parallel async calls.

The bidding write path is latency-critical: Bid API → Bid Service (validates bid amount, checks auction state) → Bid Store (a strongly consistent database — eBay uses Oracle RAC for critical transaction state) with row-level locking on the auction record. Proxy bidding is handled server-side: when a bid comes in, the Bid Service increments the current price to the minimum needed to beat the proxy bid, or updates the proxy if the new bid exceeds it. At auction close, a scheduled job (driven by a distributed timer service) finalizes the winner and triggers the Checkout Service.

A Kafka-based event bus connects all services. Listing events flow to the Search Indexer (near-real-time), Analytics, and the Trust & Safety system that scans for fraudulent listings using ML classifiers.

Core Components

Bidding Engine

The Bidding Engine handles real-time auction mechanics with strong consistency guarantees. Each auction has a single authoritative record in the Bid Store containing current_price, high_bidder_id, proxy_bid_amount, bid_count, and end_time. Bids are processed with SELECT FOR UPDATE on the auction row, ensuring serialized access. The engine supports bid increments (minimum raise rules based on current price tier), reserve prices, and automatic bid retraction rules. To handle the auction-close stampede, popular auctions are pinned to dedicated high-performance database nodes.

Search & Discovery Engine

eBay's search indexes 1.9B listings with 200+ filterable attributes per category. The index is partitioned by category and replicated 3x. Query processing: text parsing → category classification (ML model predicting likely category) → index query with filters → Best Match ranking (a gradient-boosted model trained on click-through rate, conversion, seller quality, price competitiveness, and shipping speed). Structured data extraction from listing titles (brand, model, size) uses NLP models to enable attribute-based filtering even when sellers don't fill structured fields.

Trust & Safety System

eBay's feedback system assigns each user a score based on transaction history. The Feedback Service stores buyer/seller ratings in PostgreSQL with materialized views for aggregated scores. A real-time fraud detection pipeline (Kafka Streams) scores every listing and bid against ML models trained on historical fraud patterns — features include account age, listing price deviation from market, bid velocity, and cross-account IP correlation. Flagged items enter a review queue; confirmed fraud triggers automatic account suspension.

Database Design

Listing data is stored in a sharded MySQL cluster (sharded by listing_id) with columns: listing_id, seller_id, title, description, category_id, condition, price, auction_end_time, listing_type (auction/fixed), status. A separate Cassandra cluster stores listing images and large description blobs. The bid history table (Oracle RAC for ACID guarantees) contains: bid_id, auction_id, bidder_id, bid_amount, proxy_max, timestamp. Indexes on auction_id enable fast retrieval of all bids for an auction.

The feedback/reputation data uses PostgreSQL with a star schema: a Transactions fact table linked to Feedback dimension containing rating (positive/neutral/negative), comment, and detailed seller ratings (item accuracy, shipping speed, communication). Materialized views pre-compute seller scores refreshed every 15 minutes.

API Design

• POST /api/v1/items/{item_id}/bids — Place a bid; body contains max_bid_amount; returns current_price, high_bidder status, and bid_count
• GET /api/v1/search?q={query}&category={id}&condition=used&price_min=10&price_max=100&sort=best_match — Search listings with filters and ranking
• POST /api/v1/items — Create a listing; body contains title, description, category, images, price/starting_bid, duration; returns item_id
• GET /api/v1/users/{user_id}/feedback?role=seller&period=12months — Fetch seller feedback summary and recent reviews

Scaling & Bottlenecks

The auction-close stampede is eBay's unique scaling challenge. In the final 10 seconds of a popular auction, thousands of bids arrive simultaneously for a single auction row. eBay mitigates this with: (1) dedicated database shards for high-traffic auctions detected by bid velocity monitoring; (2) an in-memory bid buffer that accepts bids into a Redis sorted set and flushes to the authoritative DB in micro-batches every 100ms; (3) optimistic locking with retry — bids that fail the version check are automatically retried up to 3 times with exponential backoff.

Search scaling for 1.9B listings uses a tiered index: hot items (listed in the last 7 days or with recent bids) are in a fast SSD-backed index; cold items (older fixed-price listings with no recent activity) are in a slower disk-backed index. Query routing checks if the query needs cold results and fans out accordingly. This reduces the SSD storage requirement by 70%.

Key Trade-offs

• Oracle RAC for bid state over distributed NoSQL: ACID guarantees with row-level locking prevent double-winning auctions — the trade-off is vertical scaling limits and licensing cost
• Proxy bidding server-side: Prevents bid sniping tools from seeing proxy amounts, but adds complexity to the bid evaluation logic
• Near-real-time search indexing (30s lag): Newly listed items aren't instantly searchable, but the reduced indexing pressure allows the search cluster to handle 1.9B documents
• Tiered search index (hot/cold): Reduces infrastructure cost by 70% but adds query routing complexity and slightly higher latency for queries that need cold results