DOCUMENTWRITE-UP

Cutting checkout latency

How a slow, coupled checkout became a fast one — situation, complication, resolution.

Situation

Checkout p95 had crept to 2.4s. Each order did three synchronous downstream calls before returning, so the slowest dependency set the floor for everyone.

SECTION 01 · Drivers

What was pushing on the design

Latency budget
Checkout must return under 800ms at p95.
GOAL: speed
Independent failure
A downstream outage must not fail checkout.
GOAL: resilience
Team autonomy
Squads must deploy consumers on their own cadence.
GOAL: decoupling
SECTION 02 · Note

Complication

Warning
Shipping, billing, and analytics were called inline and serially, so checkout latency was the sum of all three — and any one failing failed the order.

Approaches explored

SECTION 03 · Options
AParallelize the calls
Fan the three calls out concurrently.
  • Small change
  • Still coupled to the slowest
  • Still fails together
REJECTED
BPublish events
Return after publishing; consumers react async.
  • Checkout no longer waits
  • Independent failure
  • Eventual consistency
CHOSEN
SECTION 04 · Spec

The chosen approach

Boundary
Checkout commits the order, publishes OrderPlaced, and returns.
Consumers
Shipping, billing, and analytics subscribe and react on their own.
Flow
Commit orderPublish eventReturn 201Consumers react

How it works

SECTION 05 · Sequence
FLOW
Sequence diagramClientCheckout APIEvent bus1POST /orders2publish OrderPlaced3201 Created