Marketplace Seller Platform

Third-Party Sellers, Offers and Payouts

Design a marketplace where independent sellers list products, sell to buyers through one checkout, and get paid after the marketplace takes its fees, with every cent traceable.

Overview

A marketplace sells other companies' goods. Sellers bring products and stock; the marketplace brings buyers, checkout and payments, and takes a fee on each sale. The same product (one pair of headphones) is often sold by many sellers, so the platform separates the catalog product (what the thing is) from the offer (who sells it, at what price, how fast they ship, how many they have).

The hard parts are about trust and money. The platform must know who its sellers are before paying them; in the US a marketplace is required by law to collect and verify information about high-volume sellers. It must decide which offer a buyer sees first on a product page, thousands of times a second. And it must take one payment from a buyer, split it among several sellers, hold it while refunds are possible, and pay each seller the right amount, with a record that explains every cent.

Questions to ask first

Who ships the goods? — Sellers ship their own orders; a platform-fulfilled option adds a fulfillment fee
Can one cart hold items from several sellers? — Yes, one payment for the whole cart
How big? — 1M sellers, 100M offers, 5M orders a day, 500M product page views a day
How does the platform earn? — A referral fee as a percentage of the sale, plus fulfillment fees (our example: 15% and $4)
When are sellers paid? — Weekly, for money past a hold period after delivery
Which countries? — The US first, so US seller-verification rules apply

What you will be able to do

Model catalog products, offers and orders so that many sellers can sell one product.
Explain seller verification and what US law requires of a marketplace.
Pick the featured offer quickly and deterministically, and keep it fresh.
Reserve stock across several sellers in one checkout without overselling.
Design a double-entry ledger for fees, holds, refunds and payouts.

Key concepts

Catalog product vs offer
Seller verification (KYC/KYB)
Featured offer selection
Stock reservation
Split payments
Double-entry ledger
Hold period and payouts
Seller performance metrics
Shard by seller

Functional requirements

Sellers sign up, pass identity, business and bank checks, and then list offers
Sellers create offers on catalog products (price, stock, shipping speed), one by one or in bulk
Product pages show a featured offer and the list of other offers
Buyers check out a cart with items from several sellers in one payment
The platform computes fees at the sale and shows sellers their pending and available balances
Sellers are paid on a schedule; refunds and claims are taken from their balance
Seller performance metrics are tracked, with warnings and suspension for poor service

Non-functional requirements

The featured offer is read from a cache in a few milliseconds (a target we chose)
Offer price and stock changes show on product pages within about a minute
Stock is never oversold: a reservation is atomic per cart
Money is exact: integer cents, every transaction balances, nothing is edited in place
Payouts are idempotent: a retried payout run never pays a seller twice

Interview questions

How do you pick the featured offer on a product page?
How do you keep a multi-seller checkout from overselling?
How does money flow from the buyer to the sellers?
Why a double-entry ledger instead of a balance column?
What does US law require of seller onboarding?
How do you handle a refund after the seller was paid?
How do you compute seller metrics fairly?
How do you shard this system?