Marketplace Mixed
balancedSummary
Multi-modal workload combining read-heavy listing search, transactional order processing, notification fan-out, and background analytics. The read path (search, browse) and write path (checkout, inventory) have very different consistency and latency requirements that must be architecturally separated.
Example Systems
- ·E-commerce marketplace (eBay, Etsy)
- ·Gig economy platform (Uber, DoorDash)
- ·B2B procurement marketplace
- ·Real estate listing platform
- ·Travel booking marketplace
Characteristics
Capacity
Access Patterns
Recommended Patterns
Patterns to Avoid
Basis
Marketplace architectures are extensively documented through eBay, Shopify, and DoorDash engineering blogs
Related Architecture Knowledge
Outbound: this entity affects
Marketplace mixed workloads serving multiple seller accounts benefit from tenant isolation to prevent high-volume sellers from degrading the experience of all other sellers on shared infrastructure.
Full relationship →Marketplace workloads are highly susceptible to hot partitions: viral listings, celebrity sellers, and flash sales concentrate enormous traffic on a small number of items or sellers, overwhelming the shards or database rows that store their data.
Tradeoffs
- ·Write sharding for viral items requires a read aggregation step: adds latency for total inventory reads
- ·Pre-sharding hot keys requires identifying them before the spike: reactive resharding is too slow
- ·Redis-based inventory counters sacrifice ACID guarantees: requires reconciliation with the relational database
Marketplace mixed workloads are vulnerable to tenant noisy neighbor when high-volume sellers concentrate write activity on shared infrastructure, degrading performance for other sellers.
Full relationship →Used In Architecture Scenarios
Marketplace Platform
An e-commerce order lifecycle platform handling cart, checkout, payment, fulfillment, and returns across a mixed read/write workload where product discovery is read-heavy, checkout is write-transactional, and fulfillment is event-driven. The saga pattern orchestrates multi-step checkout: reserve inventory → charge payment → confirm order → notify fulfillment. PostgreSQL owns order records and inventory with row-level locking; Redis holds session state and cart contents with sub-millisecond access; RabbitMQ delivers fulfillment notifications with dead-letter handling; Elasticsearch serves product search and order history with faceted navigation. CQRS separates the write command path from the read model: the order read model is denormalized for fast order history queries without joining across domain tables.
Marketplace Platform
A two-sided marketplace architecture serving buyers, sellers, listings, transactions, search, and notifications from a shared infrastructure, where multiple independent domains must coordinate without tight coupling. Event sourcing captures every state transition; the saga pattern orchestrates multi-step transactions (create order, reserve inventory, charge payment, notify seller) with compensating transactions for partial failures. Kafka decouples domain event publication from consumption; RabbitMQ handles notification fanout; Elasticsearch serves listing search; Redis caches listing display and session state.