API Gateway Platform  ·  View 12 of 21  ·  Runtime

A Request From TLS to Upstream

Fifteen messages, of which exactly two leave the pod.

Editable source SVG draw.io All views
Caller Global LB + Armor Envoy proxy Resident state Counter store Upstream group Usage bus 1. TLS 1.3, POST /v2/orders 2. WAF, geo, DDoS 3. forward, region-local 4. admit: size, headers, timeouts 5. verifier + denylist lookup 6. principal: tenant, scopes, tier 7. scope check for this route 8. 4 scopes, one round trip 9. allow, remaining 812 10. route + version + variant 11. v2 stable, 95% weight 12. mTLS + signed identity header 13. 201 Created 14. access record, non-blocking 15. 201 + limit headers + request id A Request From TLS to Upstream Two of the fifteen messages leave the pod: the counter round trip and the upstream call. Nothing on this page reaches the control plane. v 1.0 · owner Integration Platform Architecture · date 2026-09

Read this against the latency budget

  • Messages 5, 7 and 10 — credential, scope and route resolution — are in-process reads of resident state. On most designs these are network calls, and they are the reason most gateways cannot hold a 15 ms p99.
  • Message 8 evaluates all four limit scopes in a single counter round trip. Four sequential round trips would blow the budget on their own.
  • Message 14 is fire-and-forget. A saturated telemetry pipeline must never become request backpressure.

Numbers

  • Gateway-added p99 ≤ 15 ms in-region; ≤ 25 ms when a cache miss forces a credential lookup (assumptions).
  • Counter call timeout 5 ms, no retry — a slow counter degrades to local limiting rather than to latency.

Risks

  • The cache-miss path is the tail. If the miss rate is materially above the assumed level, the p99 is set by the credential store rather than by the proxy, and ADR-03's token lifetime should be revisited.