system design · system-design

Design an E-Commerce Platform (Amazon-style)

Catalog + search + cart + order + payment + inventory + fulfillment decomposed into services. The "draw the whole company" architecture round.

hard5hawsgeneralsqlsystem-design
Ask GPTConfidence

Theory

Explanation

Intuition first, formal definition second. Skim the bullets if you already know this; read the prose if you don't.

Each domain becomes a service that owns its data and exposes APIs. Reads are denormalized + cached; writes are coordinated via sagas because no single transaction spans services. The frontend composes from many APIs; eventual consistency is acceptable everywhere except payments.

Service map: Catalog (product metadata, denormalized read store), Search (Elastic/OpenSearch index), Cart (per-user KV with TTL), Pricing (rules engine + promotions), Inventory (per-warehouse stock + reservations), Order (saga orchestrator), Payment (PCI-isolated tier), Fulfillment (warehouse + carrier integration), Recommendation (offline + online ranking), Reviews (write-once + moderation). Async event bus connects them; CDC pipes write-side data into search + recommendation pipelines.

When to use

Any large marketplace product. Pattern generalizes to food delivery, ride-hailing, ticket platforms.

When not to

Small monolithic shops, over-engineered. PCI scope ballooning when payments not isolated.

flowchart LR
  Client([Client]) --> Edge[Edge / CDN]
  Edge --> GW[API Gateway]
  GW --> Cat[Catalog]
  GW --> Search[Search]
  GW --> Cart[Cart]
  GW --> Order[Order Saga]
  Order --> Inv[Inventory]
  Order --> Pay[Payment · PCI]
  Order --> Ful[Fulfillment]
  Cat -.CDC.-> Search
  Order -.events.-> Reco[Recommendation]
  Cart -.events.-> Reco
  Reco -.serve.-> GW

Key insights

  • Search and recommendation are downstream consumers, never the source of truth for product data.
  • Cart can be lossy (eventual consistency) but cannot lose paid checkouts, separate write paths.
  • PCI scope shrinks if payment data never touches non-payment services; pass tokens, not card numbers.
  • Order saga handles distributed transaction: reserve inventory → charge payment → confirm shipment → on any failure, run compensating actions in reverse.
  • Reads dominate (100:1). Catalog + Search must scale independently of write services.