Design Online Marketplace — System Design Interview Guide

Functional requirements

• Sellers list items with title, description, photos, price, shipping, and category
• Buyers search and browse listings with filters (category, price, condition, shipping)
• Buy now or auction-style bidding with auto-bid
• Order management: place order, pay, track shipment, leave feedback
• Seller ratings and reviews
• Messaging between buyers and sellers

Non-functional requirements

• Scale: ~150M MAU buyers, ~20M active sellers, ~1.5B active listings
• Search latency: <400ms p99 for keyword + filter queries
• Listing-create latency: <1 sec p99 from submit to visible in seller's listings
• Auction-bid latency: <500ms p99 from bid submit to confirmation (real-time bidding during last minutes is critical)
• Availability: 99.95%; payment failures must roll back inventory holds

Capacity estimation

Public scale anchors (eBay/Etsy combined-style): ~150M MAU, ~20M active sellers, ~1.5B active listings. Daily new listings ~5M/day, daily orders ~3M/day. Daily search queries ~500M/day = ~6K/sec average, ~30K/sec peak.

Storage: each listing ~5 KB metadata (title, description, attributes, seller info, pricing). 1.5B listings × 5 KB = ~7.5 TB. Listing images dominate byte storage: average 5 images × 200 KB compressed = 1 MB/listing × 1.5B listings = 1.5 PB images (stored in object storage, served via CDN).

Search index: full-text over titles + descriptions + structured filters (price range, category, condition, location). Index size ~3x raw text = ~25 TB. The index is sharded by category prefix for query pruning; popular categories have dedicated shards.

Write QPS: listings ~60/sec average, ~500/sec peak. Bid events on active auctions ~50K bids/day average × 50x peak factor at auction close = ~30K bids/sec peak (concentrated in the last minute of high-traffic auctions). Order writes ~30/sec.

User-facing reads dominate: search results ~6K/sec, listing-detail page loads ~30K/sec at peak. Buyer activity history (recently-viewed, watch list, saved searches) is voluminous — append to a per-user activity log.

High-level design

Six core services: catalog, search, bidding/checkout, payments, fulfillment, and messaging. Each shards by different keys.

Catalog service stores listing records in a sharded relational store keyed by listing_id. Each row holds the structured fields (title, price, category, attributes, seller_id, inventory_count, created_at, expires_at). Listing photos go to object storage with CDN front; the listing row holds image URLs. Catalog reads are cached aggressively because the same listing is viewed by many buyers.

Search service maintains an inverted index over listing text and structured attributes. The index is built from the catalog stream: every catalog write emits a change event consumed by an indexing pipeline. Index updates are visible within minutes (eventual consistency is acceptable for search). Queries return ranked listing IDs; a re-ranker scores candidates using freshness, seller reputation, listing quality (photo count, description length, completeness), and personalization.

Bidding service handles auction state. Each active auction has an in-memory representation (current high bid, bidder ID, auto-bid ceilings, scheduled close time) on a dedicated server (the auction is sharded to a single owner for serialization). Bids are written to the durable log on the way through; the in-memory representation is the source of truth during the live auction window. At close, the final state is committed to the order pipeline.

Checkout service handles 'buy now' purchases: it reserves inventory on the catalog record (atomic decrement), creates an order row in the order store, and routes to payments. Failed payments release the inventory hold.

Payments service is its own subsystem with separate vault for stored payment methods. It integrates with payment processors (cards, wallets, regional methods). Each payment is two-phase (authorize, capture) so failed captures don't strand customers.

Fulfillment service tracks shipping events from sellers (label printed, in transit, delivered). Some marketplaces handle shipping themselves (managed shipping); others let sellers ship independently and just record events.

Messaging is a separate service: buyer-to-seller messages, stored in a per-conversation thread sharded by conversation_id.

Deep dive — the hard problem

Two deep dives: search ranking over a heterogeneous catalog, and auction concurrency at close.

Search over heterogeneous catalog: unlike a structured catalog (e.g. a single retailer's products), a marketplace catalog spans hand-knit scarves, vintage cameras, and used books. Listings have wildly different structure, quality, and freshness. Naïve keyword search returns garbage.

Production marketplace search is a multi-stage funnel. Stage 1 (retrieval): the inverted index returns the top ~10K candidates matching the keyword and filters. Stage 2 (ranking): a ranker model scores each candidate using listing features (title quality, photo count, price competitiveness, seller rating) and buyer-context features (buyer's past purchases, location, currency). Stage 3 (diversification): post-process to avoid result-page collapse — no more than 3 listings from the same seller, mix newly-listed with established listings, mix price ranges.

The ranker is critical. Buyers reward fresh, high-quality, well-priced listings; sellers reward exposure that converts. The ranker model is trained on historical purchase data and refreshed periodically. Mention this — the senior signal is recognizing that marketplace search is a ranking problem under quality and freshness signals, not a string match.

For seller-side fairness, production marketplaces apply ranking floors: a new seller with 0 reviews doesn't dominate over an established seller with 10K reviews unless their listing is dramatically better-matched. Similarly, sellers with poor metrics (high cancellation rate, low response time) are demoted. Mention these as inputs to the ranker.

Auction concurrency: an active auction in its last minute can receive hundreds of bids per second from competing bidders. The bid must be serialized — only one bid can be 'current high bid' at a time. Naive write-to-database serialization fails because the database can't handle 30K writes/sec on a single row.

The production answer is a per-auction in-memory state owned by a single server. All bids for that auction route to that server (sharded by auction_id). The server holds the current high bid, the high bidder, and any active auto-bid ceilings. Each incoming bid is processed in-memory in O(microseconds): compare to current high, update if higher, send rejection/confirmation to the bidder. Auto-bidding (where a bidder set a ceiling) executes locally — if a competing bid arrives at price X and the previous high bidder had an auto-bid ceiling of X+10, the system immediately increments to X+10 in their name.

Durability: each bid is also written to a durable append-only log for replay. On server failure, the auction state can be rebuilt from the log. The in-memory state is the live source of truth during the auction; the log is the recovery source. At auction close, the final state is committed to the order pipeline.

For very popular auctions (~100K watchers, ~30K bids in last minute), the server holding that auction can be a bottleneck. Solutions: pre-warm the server (give it the auction in isolation), throttle low-bid spammers at the edge, and use a write-batching pipeline within the server. Mention but don't drill in.

Third tradeoff: inventory consistency. A single 'buy now' listing with quantity 1 must not sell twice. The atomic-decrement on the catalog row handles this. For listings with quantity >1, eventual consistency is acceptable — a small chance of overselling by 1-2 units is tolerated, with a refund-and-apologize path.

Common mistakes

• Treating marketplace search as keyword match — without ranking by quality, freshness, and seller signals, results are unusable
• Storing auction state in the durable database with a transaction per bid — sub-millisecond bid latency at high concurrency is impossible
• Forgetting payment two-phase — when capture fails, you must reverse the inventory hold or strand customers
• Skipping seller-side fairness in ranking — pure relevance ranking lets one dominant seller capture all queries
• Designing inventory as eventually-consistent for unique items — overselling a one-of-a-kind item destroys customer trust

Likely follow-up questions

• How would you implement a fraud-detection layer that catches stolen-card purchases without false-flagging legitimate buyers?
• What changes if you have to support cross-border purchases with customs forms and currency conversion?
• How would you handle a viral listing that gets 100K watchers and 50K bids in its last hour?
• How would you implement a buyer-protection program that holds payment until delivery is confirmed?
• How would you support category-specific features (size charts for clothing, technical specs for electronics)?