Programmable Messaging API  ·  View 14 of 22  ·  Runtime

Receipt Ingest And State

Verify, acknowledge, correlate, fold — in that order, because the carrier will not wait.

Editable source SVG draw.io All views
Arrival Carrier receipt 25k/s, 100k/s burst Verify origin signature or allowlist Admit Dedup route + provider ref Receipt stream durable before ack Ack carrier p99 under 250 ms Correlate Match to attempt by provider reference Quarantine never discarded Fold Monotonic apply terminal is terminal TTL sweeper no receipt = unknown Message ledger append the fact Serve State projection Bigtable Route quality signal feeds routing Notify Callback dispatch signed, retried Callback DLQ pull still works Status API the fallback of record unknown reference expiry is a fact delivery rate exhausted Receipt Ingest — Verify, Correlate, Fold, Notify External / third party Security / platform Application we own Queue / topic Interface / broker Risk / gap Data store failure / alternate synchronous event / async A receipt is acknowledged once it is durable, long before it is understood. v 1.0 · owner Integration Platform Architecture

Decisions

  • A receipt is acknowledged once durable, long before it is understood: the carrier's timeout is shorter than the platform's correlation.
  • The TTL sweeper is a first-class producer of facts: "no conclusive receipt by the deadline" is appended as the reason a message became unknown.
  • Callback exhaustion goes to a dead-letter path and never changes the message's state; pull remains authoritative for the tenant.

Assumptions

  • 25,000 receipts/second steady, 100,000/second for 5 minutes; inbound acknowledgement p99 ≤ 250 ms.
  • Receipts correlated to the wrong attempt ≤ 1 per 10,000,000; backwards transitions out of a terminal state: zero.

Risks

  • A rising quarantine rate is the earliest signal of a correlation bug and the easiest thing to stop looking at.