Service Mesh Platform  ·  View 11 of 31  ·  3 · Structure

Anatomy of One Meshed Call

The eight decisions two proxies make between checkout and ledger, and the three local inputs every one of them reads.

Editable source SVG draw.io All views
Caller pod checkout app forwards trace · deadline Outbound proxy Route match subset · weight Timeout · retry budget GET only · 20% Outlier · limits locality first On the wire mTLS SVID · TLS 1.3 Inbound proxy Identity verify chain + expected SAN Authorisation in-proxy · 0.2 ms Concurrency limit shed, never queue Callee pod ledger app sees caller identity Anatomy of One Meshed Call — Every Decision Reads Local State Application we own Interface / broker Decision point Security / platform Three local inputs decide everything here: last-good config, the trust bundle and an unexpired SVID. None is fetched per request. v 1.0 · owner Platform Networking Architecture · date 2026-09

Decisions

  • The inbound proxy checks both the chain and the peer's identity against the set the destination expects. A valid certificate from the right root but the wrong service is refused.
  • Load is shed at the callee's proxy with a fast 503 once concurrency reaches its limit. Queueing hides overload until it becomes an outage.
  • Retries happen on the caller's side only, for declared idempotent methods, within a per-destination budget. The callee never retries on the caller's behalf.

Budget

  • Added latency per hop p50 ≤ 0.5 ms, p99 ≤ 1.5 ms at ≤ 2,000 rps per proxy; ≤ 3 ms p99 for the call. Authorisation p99 ≤ 0.2 ms. Cold mTLS handshake p99 ≤ 8 ms, amortised by connection reuse.

Requires of the application

  • Forward trace context and the deadline header on outbound calls. The mesh cannot correlate a hop it did not see the context for; this is the one change the platform asks of every team.