E-commerce order processing

An e-commerce order processing architecture is a picture of the parts that take an order from a storefront to a courier: web and mobile hit a CDN and an API gateway, which fans out to auth, catalogue, search, cart and orders. Risky payments go to manual review before the payments provider; that provider and the courier call back through a webhook handler. Failed fulfilment lands on a dead-letter queue that can replay onto the order queue.

People draw this one to onboard engineers onto a retail platform, to show a security review where payment and fraud actually sit, or to explain why a missing webhook prevents an order from shipping. Grouping of nodes is important in this drawing: storefront, edge, services, data, async jobs and third parties are different trust and failure domains, and a flat mix of boxes doesn't make that visible.

Open in editor

Mermaid source

---
title: E-commerce order processing
---
flowchart TD
  subgraph shopper [Shopper]
    web[Web storefront]
    app[Mobile app]
  end
  subgraph edge [Edge]
    cdn[CDN]
    gw[API gateway]
    wh[Webhook handler]
  end
  subgraph svc [Services]
    auth[Auth service]
    catalog[Catalogue service]
    search[Search service]
    cart[Cart service]
    order[Orders service]
    pay[Payments service]
    fraud{Risky?}
    review[Manual review]
    inv[Inventory service]
  end
  subgraph data [Data]
    udb[(Users DB)]
    pdb[(Products DB)]
    sdb[(Search index)]
    odb[(Orders DB)]
    cache[(Session cache)]
  end
  subgraph async [Async jobs]
    q[[Order queue]]
    fulfil[Fulfilment worker]
    mailer[Email worker]
    dlq[(Dead letter queue)]
    cron[Nightly reconcile]
  end
  subgraph ext [Third parties]
    psp[Payments provider]
    courier[Courier API]
    smtp[Email provider]
  end
  web --> cdn
  app --> cdn
  cdn --> gw
  gw --> auth
  gw --> catalog
  gw --> search
  gw --> cart
  gw --> order
  auth --> udb
  catalog --> pdb
  catalog --> cache
  search --> sdb
  cart --> cache
  cart --> inv
  inv --> pdb
  order --> odb
  order --> pay
  pay --> fraud
  fraud -->|No| psp
  fraud -->|Yes| review
  review -->|cleared| psp
  psp -->|payment webhook| wh
  courier -->|tracking webhook| wh
  wh --> order
  order --> q
  q --> fulfil
  q --> mailer
  fulfil --> courier
  fulfil --> odb
  fulfil -->|failed| dlq
  dlq -->|replay| q
  mailer --> smtp
  cron -.-> psp
  cron -.-> odb

Stock Mermaid vs Line9 on this e-commerce architecture

Run the same source through the stock Mermaid engine and it often will not look as good. In some cases, Mermaid is able to deliver a usable graph, but not always. On this one:

The same e-commerce architecture through stock Mermaid — Data overlapping Services, a webhook handler isolated in Edge, and gateway fan-out as a bundle of long edges — Stock Mermaid, same source View full size ↗

The stock Mermaid rendering looks worse than the Line9 version because the edges between the Edge group and the Services group, and between the Services and Data group are tightly packed together and so are very difficult to trace accurately. The edges also run behind nodes rather than around them which again reduces readability. These are common problems in more complex graphs when laid out using the dagre renderer.

For a fuller product comparison — layout, export, CLI, and pricing — see Line9 vs mermaid.live.

Render your own

Paste any Mermaid flowchart into the free online editor — no account needed. Prefer the terminal? Install the line9 CLI (free for personal use).

More scenarios on the Mermaid examples hub.

Mermaid source

Stock Mermaid vs Line9 on this e-commerce architecture

Render your own

Related diagrams