Large-Scale Marketplace System Design

What's being tested

Interviewers probe the candidate's ability to design a reliable, scalable two-sided marketplace backend that balances availability, consistency, security, and operational complexity. They're looking for system decomposition skills (services, data models, APIs), datastore and caching choices for different access patterns, and pragmatic tradeoffs around payments/escrow, media storage, search/ranking, and fraud prevention. Also evaluated: capacity planning, failure modes, and how you instrument and evolve the system.

Core knowledge

• Entity data model: represent core objects (User, Listing, Order, Payment, Review) with clear ownership and lifecycle; normalize vs denormalize where read latency matters; expected cardinalities (users U, listings L ~ millions).

• Datastore choices: use Postgres for transactional operations and metadata with strong ACID; use wide-column store like Cassandra or DynamoDB for high-write catalogs and denormalized read patterns at massive scale.

• Search & discovery: index listings in Elasticsearch for full-text, faceting, and geo queries; keep the search index eventually consistent and design changefeeds to sync DB → index.

• Media handling: store images/video in S3 (or object store), serve via CDN for p99 latency, and use background jobs for thumbnails and content moderation.

• Payments & escrow: isolate payments in a dedicated service; follow idempotency patterns (idempotency-key), avoid distributed transactions—use local DB transactions plus compensating actions or an escrow state machine for holding funds.

• Consistency models: choose strong consistency for order/payment state transitions; accept eventual consistency for catalog visibility and search to maximize availability and throughput.

• Scaling & sharding: shard user-related state by user_id; shard listings by category or geo when L > ~10M; use consistent hashing for stateless services and caches.

• Caching patterns: front-line Redis caching for hot listing and user sessions; cache invalidation via pub/sub/event notifications when writes occur.

• Messaging and integration: use Kafka or stream platform for durable changefeeds, async workflows, and audit trails; partition by entity key for ordering guarantees.

• Realtime interactions: use WebSocket or SSE for live bidding/notifications; keep these paths lightweight and stateless (token-based auth).

• Security & compliance: PCI DSS constraints require tokenized card storage through external providers (Stripe/Adyen); minimize scope of systems that handle raw card data.

• Observability & SLOs: measure p50/p95/p99 latencies, error rates, and business metrics (conversion, gross merchandise volume); design tracing for cross-service transactions.

Worked example — Design an online marketplace for buying and selling

Start by clarifying scope: fixed-price vs auctions, primary/secondary goods, expected scale (daily active users, listings), geographic footprint, and who handles payments/returns. Organize the design around five pillars: (1) data model and persistence for Listings/Orders/Users; (2) API layer and service boundaries (Listing Service, Order Service, Payment Service, Search Service, Media Service); (3) search & discovery with Elasticsearch and changefeed sync; (4) payments & escrow with idempotency, state machine, and external PSP integration; (5) operational concerns (moderation, fraud detection, observability). Explicit tradeoff: using a single ACID DB for everything simplifies correctness but won't scale—prefer Postgres for payments and a denormalized read-store for catalog queries, accepting eventual consistency in search and feeds. When describing order flow, show how you avoid distributed two-phase commit: perform local DB transaction to lock inventory, call PSP to authorize with idempotency, and use compensating actions on failure. Close by saying: if time permits, diagram APIs, show example DB schemas, define SLOs and capacity numbers, sketch event schemas for Kafka, and outline a phased rollout and load-testing plan.

A second angle — auction-style marketplace or high-frequency bidding

If bids and auctions are in scope, real-time constraints dominate. The architecture shifts toward low-latency pub/sub (WS gateways), strong sequencing of bid operations, and optimistic concurrency with fast conflict resolution. You'd place the auction state in a low-latency store (in-memory shard per auction with persistence), use ordered Kafka partitions for bid events, and prioritize consistency for the current highest bid while still making historical events eventually consistent. This requires careful cost analysis: supporting thousands of concurrent auctions needs sticky routing and autoscaling of WS gate nodes, while replayable event logs enable dispute resolution and audit.

Common pitfalls

Pitfall: Designing everything as ACID with distributed transactions — tempting but usually unnecessary; it causes latency, complexity, and operational burden. Instead, use local transactions plus explicit state machines and compensating actions for cross-service workflows.

Pitfall: Ignoring fraud and moderation in the architecture — assuming "we'll add it later" leads to costly refactors. Build pluggable moderation and fraud scoring hooks into listing creation and payment flows from the start.

Pitfall: Overfocusing on micro-optimizations instead of SLOs — naming microservice boundaries without defining SLOs and capacity targets leads to unclear scaling decisions; define p99 latency and throughput goals first.

Connections

Interviewers can pivot to adjacent topics like search relevance and ranking (how to incorporate ML features into ranking pipelines), payments infrastructure (tokenization, chargeback workflows, reconciliation), or data pipelines for analytics and experimentation that rely on the system's changefeed.

Further reading

• Designing Data-Intensive Applications — Martin Kleppmann — architecture patterns for consistency, streams, and data models that map directly to marketplace challenges.

• Stripe Engineering Blog — practical guidance on payments, idempotency, and operational patterns for handling money at scale.