Commerce & payments · Advanced

E-commerce checkout

Cart, orders, inventory and payments with idempotency and an outbox.

Every part, and why it is there

Most traffic is browsing and cart edits; only a few percent of sessions place an order, but those requests must never be lost or doubled.

Product images and static files served from the edge, keeping them off the checkout path.

Spreads API calls across service replicas and removes unhealthy ones.

Carts change constantly and can be rebuilt if lost, so they live in Redis rather than the orders database.

Runs checkout: reserve stock, charge the card, record the order. Each step is retried safely using an idempotency key.

Owns stock counts. Reserving stock is a single conditional update, so two shoppers cannot buy the last item.

Fast key-value store for carts with an expiry, so abandoned carts clean themselves up.

Orders are money: a relational database with transactions and a standby in another zone so a failure loses nothing.

Separate from orders so inventory can change without touching checkout tables.

Stripe or Adyen charges the card. It is slow and sometimes times out, so every call carries an idempotency key.

The order and its event are saved together, then delivered from here. If email is down, events wait instead of failing checkout.

Sends confirmation emails from order events, retrying until the provider accepts them.

SendGrid or SES delivers the email. Outsourced because deliverability is its own hard problem.

Original product photos; the CDN caches them at the edge.