Programmable Messaging API  ·  View 13 of 22  ·  Runtime

Critical Flow — Submit To Carrier Acceptance

Eighteen messages, and the one that promises ownership rather than delivery.

Editable source SVG draw.io All views
Tenant app Send API Compliance Message ledger Scheduler Attempt executor Session plane Carrier 1. POST message, client reference 2. normalise, sender and jurisdiction check 3. dedup on client reference 4. no prior message 5. consent, quiet hours, content 6. allow, rule set v412 7. append submission 8. committed, RPO 0 9. 202 accepted, id, segments 10. enqueue, interactive lane 11. lease, fairness checked 12. select route, take throughput lease 13. append attempt intent 14. submit on bind 15. submit_sm 16. accepted, provider reference 17. append attempt outcome 18. throttled: park with release time Critical Flow — Submit To Carrier Acceptance For An Interactive Message The acknowledgement at step 9 promises ownership, not delivery. Nothing after it blocks the tenant. v 1.0 · owner Integration Platform Architecture

Decisions

  • Step 9 returns to the tenant before any route is chosen: submission never waits on a route, a session or a carrier.
  • Attempt intent is appended before the carrier call and the outcome after, which is what makes a worker death a resume rather than a mystery.
  • Throttling is drawn as a park with a release time, on the same path as success — not as an error branch.

Assumptions

  • Submit acknowledgement p99 ≤ 400 ms in-region, of which the ledger commit is the dominant term.
  • Consent evaluation is a strongly consistent read inside the submit budget, and fails closed.

Risks

  • The consent read is on every submit at 8,000/second: if it cannot hold ≥ 99.99% it becomes the platform's availability ceiling.
◀  Data Model All views Receipt Ingest And State  ▶
Solution Architecture v1.0 · Google Cloud · Integration Platform Architecture · 2026-10 · 22 views · 16 architecture decision records13-send-sequence