DOCUMENTWRITE-UP

Cutting checkout latency

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

Situation
01 · Drivers

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
Cutting checkout latency2 / 6
Situation
02 · Note
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.
Cutting checkout latency3 / 6
Approaches explored
03 · Options
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
Cutting checkout latency4 / 6
Approaches explored
04 · Spec
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
Cutting checkout latency5 / 6
How it works
05 · Sequence
SECTION 05 · Sequence
FLOW
Sequence diagramClientCheckout APIEvent bus1POST /orders2publish OrderPlaced3201 Created
Cutting checkout latency6 / 6
1 / 6
Document