API Gateway Platform  ·  View 07 of 21  ·  Structure

Platform Components

Three planes that are deliberately not allowed to become each other.

Editable source SVG draw.io All views
Request plane — per region, stateless on the hot path Edge tier (Google-managed) Global external ALB anycast, TLS Cloud Armor WAF, DDoS, geo Managed certificates per API hostname Proxy fleet — GKE regional node pools Envoy proxy 10k rps / instance Auth filter in-process Quota filter local + shared Router filter version + variant Telemetry filter fire and forget Resident state — in the pod, never a network hop to the control plane Config snapshot signed, versioned Credential cache verifiers, 5 min TTL Revocation denylist pushed, 30 s SLO Local counters per-instance buckets Shared runtime state — the one deliberate hot-path dependency Counters Memorystore Redis sharded, in-region Cache Response cache cacheable routes only Upstreams Service group v1 stable Service group v2 canary weight Control plane — an outage here stops change, not traffic Configuration Config API RBAC, reviewed Config store Spanner, versioned Snapshot publisher signs + uploads Product and identity API product catalogue plans, scopes Credential store verifiers only Developer portal self-service Delivery and evidence Rollout controller scores, halts Analytics store BigQuery Audit ledger immutable, 7 yr Authorisation server issues tokens Billing consumes usage signed snapshot, pull revocation push shared counters usage, sampled promote / revert daily rollup Platform Components — Three Planes That May Not Become Each Other Interface / broker Security / platform Application we own Data store External / third party event / async synchronous batch Redis is the only synchronous dependency on the request path, and it is designed to be degradable rather than highly available. v 1.0 · owner Integration Platform Architecture · date 2026-09

The critical decision, drawn

  • Request plane: every per-request decision is made from state already inside the pod — the signed config snapshot, the credential cache, the denylist, the local counters.
  • Control plane: config API, credential store, product catalogue, rollout controller, audit. An outage here stops change and changes nothing about traffic.
  • Shared runtime state: the counter store is the single deliberate exception, and it is designed to be degradable rather than highly available (ADR-05).

Realisation

  • Envoy on GKE regional node pools; Google-managed global ALB and Cloud Armor at the edge.
  • Spanner for versioned global configuration; signed snapshots in a dual-region bucket; Memorystore for counters; Pub/Sub and BigQuery for evidence.
  • 10,000 requests/s per instance at ≤ 70% CPU (assumption) — the figure that sets fleet size.

Risks

  • The counter store is on the hot path and can be made slow rather than absent — a partially degraded Redis is harder to handle than a dead one, which is why the call carries a 5 ms timeout and not a retry.
  • Filter logic lives in the proxy. Filters are code on the request path and must be released with the same canary discipline as configuration (ADR-11).
◀  Layered Architecture All views Integration Surface  ▶
Solution Architecture v1.0 · Google Cloud · Integration Platform Architecture · 2026-09 · 21 views · 18 architecture decision records07-platform-components