Programmable Messaging API  ·  View 02 of 22  ·  Context and scope

High-Level Architecture

The seven stages a message passes through, and the one place durability is bought.

Editable source SVG draw.io All views
Submit Tenant application Send API Cloud Run Admit Validation destination, sender, body Consent and compliance fails closed Own Message ledger Cloud Spanner Body store Cloud Storage, CMEK Schedule and route Class lanes Pub/Sub Route pacing Cloud Tasks Route selector cost, quality, pinned Attempt Channel adapters one contract Session plane GKE StatefulSet Carrier Carrier or aggregator 220 routes Outcome Receipt ingest 25k/s State projection Bigtable Tenant callback signed, DLQ late, partial, absent append Programmable Messaging Platform — High-Level Architecture External / third party Interface / broker Application we own Security / platform Data store Queue / topic event / async State is a fold over the ledger, never a field the submit path writes. v 1.0 · owner Integration Platform Architecture

Decisions

  • Accept, own, then attempt: the acknowledgement at stage three is a durability promise, and nothing after it blocks the caller.
  • The ledger is the only synchronous durable write on the submit path; scheduling, routing and attempting are all retryable.
  • Receipts arrive back into the ledger as appended facts, never as an update to a status field.

Assumptions

  • 8,000 accepted messages/second steady state, 40,000/second for 10 minutes.
  • Interactive submit-to-carrier-acceptance p95 ≤ 2 s on a healthy route.
  • Two durable ledger writes per attempt — intent before the carrier call, outcome after.

Deliberate omissions

  • The console, IaC and per-service sidecars; see views 08 and 18.
  • Inbound traffic, which runs the same spine in reverse; see views 06 and 15.
◀  System Context All views Actors and Their Journeys  ▶
Solution Architecture v1.0 · Google Cloud · Integration Platform Architecture · 2026-10 · 22 views · 16 architecture decision records02-high-level-architecture