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

System Context

Who calls the platform, who it calls, and which dependencies it has no control over.

Editable source SVG draw.io All views
Tenant systems Tenant application OTP and transactional Campaign tool bulk Tenant identity provider People App developer 40,000 tenants Message recipient the handset Compliance officer Platform SRE Carriers and channels (not ours) Mobile network operator SMPP bind SMS aggregator HTTP WhatsApp Business Platform RCS hub Programmable Messaging Platform Submit to terminal state Adjacent platforms (out of scope) Metering and billing rated usage events Number inventory read only Regulator / ombudsman evidence on request POST /v1/messages replies STOP queries by number route health submit + receipt submit + receipt template send rich send send + status batch submit console SSO Programmable Messaging Platform — System Context External / third party Security / platform Person or role synchronous two-way Everything on the right belongs to somebody else: their window, their price, their receipt, their silence. v 1.0 · owner Integration Platform Architecture · date 2026-10

Decisions

  • The boundary is drawn at the carrier, not at the handset: the platform's commitment ends at a recorded outcome, which is why "unknown" has to be a product-visible state.
  • The paying customer (the developer) and the person the product happens to (the recipient) are different actors with different failure modes, so both are in the context.
  • Metering and invoicing sit outside: this platform's output is a rated usage event per attempt, and nothing downstream of it.

Assumptions

  • 40,000 active tenants across 190 jurisdictions, 9 channels and roughly 220 carrier or aggregator routes.
  • Phone-number inventory is an existing system the platform reads; provisioning is not in scope.
  • Regulators and ombudsmen request evidence occasionally rather than continuously, so evidence export is a batch path.

Risks

  • Every interesting dependency is on the right-hand side, with its own window, price, auth, outage and regulator.
  • A jurisdiction with one viable route is a single point of failure the platform cannot engineer away, only report.
All views High-Level Architecture  ▶
Solution Architecture v1.0 · Google Cloud · Integration Platform Architecture · 2026-10 · 22 views · 16 architecture decision records01-system-context