Queueing Network — Checkout API Call Chain
An 850-request-a-second checkout path across six services, where the payment adapter's bounded connection pool is the constraint and heavy-tailed pricing latency (cv 1.9) more than doubles the queue an M/M/c model would predict.
Make it your own.
title "Checkout API — request path at peak"
target 75%
rate unit /s
arrivals Gateway 850/s
station Gateway { servers: 8; service: 6ms }
station "Auth service" { servers: 11; service: 9ms; cv: 1.6 }
station "Cart service" { servers: 16; service: 14ms }
# Pricing latency is heavy-tailed: promo evaluation dominates the tail.
station "Pricing engine" { servers: 26; service: 22ms; cv: 1.9 }
# The connection pool is a hard limit — requests beyond it are shed, so the
# adapter is M/M/c/K rather than an unbounded queue.
station "Payment adapter" { servers: 80; service: 120ms; capacity: 240 }
station "Order writer" { servers: 12; service: 18ms }
route Gateway -> "Auth service" 1.0
route "Auth service" -> "Cart service" 0.97
route "Auth service" -> exit 0.03 # rejected tokens
route "Cart service" -> "Pricing engine" 1.0
route "Pricing engine" -> "Payment adapter" 0.62
route "Pricing engine" -> exit 0.38 # quote-only traffic
route "Payment adapter" -> "Order writer" 0.94
route "Payment adapter" -> "Pricing engine" 0.06 # re-price after a decline
route "Order writer" -> exit 1.0