Build a Marketplace Feature for Facebook — System Design Interview Practice

Interview prompt

Design a Facebook Marketplace feature where people list products, discover nearby items, search and filter inventory, message sellers, and complete listing and moderation workflows at large scale.

• Separate listing source data, search indexes, image media, messaging, and recommendation projections.
• Make location and category search scalable while keeping listing ownership and status authoritative.
• Handle ranking, seller safety, fraud, moderation, and stale inventory explicitly.
• Use asynchronous indexing and notifications without making listing creation depend on every downstream consumer.

Requirements and scale assumptions

• Create, edit, pause, and remove listings with title, description, price, category, condition, location, and photos.
• Search nearby inventory with text, category, price, distance, and freshness filters.
• View listing details, save items, contact sellers, and report suspicious listings.
• Notify sellers of messages and buyers of listing changes while supporting moderation and audit actions.
• A listing must be durable before it appears in the owner's inventory.
• Target p95 below 300 ms for a cached search page and below 500 ms for an uncached query.
• Search results may be eventually consistent but must not return deleted, blocked, or sold listings after policy recheck.
• Protect users from spam, location leakage, fraud, abusive content, and notification storms.
• 100 million active listings, 50 million daily searches, and 20,000 peak search requests per second.
• Listings have one or more images and are concentrated in geographic and category hot spots.
• Most listing edits are infrequent, but popular products and local events create hot queries.
• Messages and reports require durable delivery, while recommendations and counters are rebuildable.

• Search throughput: 20K peak/s — Provision read replicas, index shards, and cache for bursty local queries.
• Search latency: p95 <=300ms — Bound candidate retrieval, ranking, and policy filtering.
• Index freshness: p95 <=10s — New or edited listings become searchable asynchronously within the target.
• Report response: <1 minute — A report is durably queued quickly even if review is asynchronous.

Key entities

• ListinglistingId, sellerId, title, price, currency, location, status, version

  Versioned seller-owned listing and lifecycle state.

• InventoryProjectionlistingId, locationCell, category, price, availability, indexedAt

  Search-oriented listing view with freshness.

• ConversationconversationId, listingId, buyerId, sellerId, lastMessageId, status

  Buyer/seller messaging context linked to a listing.

• ModerationDecisionlistingId, policyVersion, riskSignals, decision, reviewState, createdAt

  Auditable trust and safety decision.

Data flow

1. 1. Create and moderate a listingThe listing service validates seller/account policy, media, price, location, and fraud signals before committing a versioned listing.
2. 2. Publish searchable inventoryCommitted listing changes become geo/category search events; index workers update the projection with a freshness watermark.
3. 3. Discover nearby itemsThe query service applies tenant and location policy, searches bounded shards, ranks results, and returns cursor and index version.
4. 4. Message the sellerMessages append to a conversation log, enforce listing membership and abuse limits, and deliver notifications asynchronously.
5. 5. Close, report, or repair a listingModeration and seller actions write lifecycle decisions, invalidate search/cache entries, and preserve an audit trail.

Deep dives and trade-offs

• Listing lifecycle and search freshnessFor Facebook Marketplace, only an authorized, policy-allowed listing version may appear in search or messaging. Design for the failure case where hot locations, abusive listings, stale inventory, and seller changes must not leak or misrepresent availability; keep retries, versions, and repair state explicit. Expose freshness, version, lineage, or audit metadata so operators and clients can distinguish current, pending, and degraded state.
• Geo partitioning and rankingFor Facebook Marketplace, only an authorized, policy-allowed listing version may appear in search or messaging. Keep this concern off unrelated request paths and partition it by the Facebook Marketplace access key. Expose freshness, version, lineage, or audit metadata so operators and clients can distinguish current, pending, and degraded state.
• Trust, messaging, and moderationFor Facebook Marketplace, only an authorized, policy-allowed listing version may appear in search or messaging. Keep this concern off unrelated request paths and partition it by the Facebook Marketplace access key. Expose freshness, version, lineage, or audit metadata so operators and clients can distinguish current, pending, and degraded state.
• Strong listing consistency versus search freshnessCommit listing state synchronously and accept eventual search projection with visible freshness and tombstones. Making every search read synchronously hit listing storage hurts geo-query latency and scale.
• Geo sharding versus global rankingShard by location cell and category, then rank within a bounded candidate set. A global scan gives better ranking but makes hot cities and broad searches expensive.
• Open messaging versus trust controlsAllow low-friction contact with rate limits, spam detection, reporting, and seller/buyer blocking. Strict synchronous moderation can block legitimate commerce; no controls turns messaging into an abuse channel.