Design Multi-Vendor Marketplace

Problem Statement: Multi-Vendor Marketplace

A multi-vendor marketplace is a three-sided system: independent sellers list inventory, buyers purchase through one unified storefront, and the platform in the middle orchestrates payments, commissions, disputes, and trust. The defining difference from single-merchant e-commerce is that every write must answer questions a single store never faces — which seller owns this SKU, who gets paid when it sells, and what happens when one cart's items ship from three different warehouses? Amazon Marketplace, eBay, and Etsy interviews all probe the same tension: can you keep the buyer experience monolithic (one search, one cart, one checkout) while keeping seller data federated (isolated catalogs, balances, and payouts)?

The architectural spine is that seller_id is the tenancy boundary for catalog and money, while the buyer session stays global. Two sellers offering the same manufacturer SKU are two distinct offer rows — the platform never silently merges their inventory or price, because they are independent businesses with independent stock and reputations. Commission accrues to a sub_order_id at capture time and is snapshotted, so changing the take rate next month never retroactively rewrites a fee that was already locked. That "snapshot the money the moment it moves" discipline is what keeps the ledger auditable.

The hard cases — the ones an interviewer reaches for — all live at the seams between the three sides. A multi-item cart whose items belong to different sellers must split into per-seller sub-orders that can ship, partially ship, cancel, and refund independently. A seller flipping to vacation mode mid-checkout, concurrent price edits during a quote's TTL, and a chargeback that arrives after a payout has been released are not edge cases to wave at — they are the core of why the design is hard.

Scale frames the rest: roughly 50 million buyers, 2 million active sellers, and 80 million offers (the SKU-by-seller cross-product), with a billion listing views a day funneling to tens of millions of orders. The consistency posture follows from the three sides: search and seller dashboards are AP (a slightly stale result never loses money), while orders, payments, and the payout ledger are CP (a double-pay or a lost order is a financial incident). Stating that split up front is what makes every later decision coherent.