Programmable Messaging API  ·  View 16 of 22  ·  Runtime

The Ambiguous Submit

One attempt, two legitimate endings, and a policy recorded on the message.

Editable source SVG draw.io All views
Attempt executor Message ledger Session plane Carrier Route policy TTL sweeper Tenant 1. append intent, attempt 1 2. submit 3. submit_sm, sequence 8841 4. no response, window timeout 5. append outcome: ambiguous 6. does this route support query? 7. no query, do not re-attempt 8. record the policy applied 9. late receipt, delivered 10. if TTL elapses first: unknown 11. status = delivered or unknown, with the attempt trail The Ambiguous Submit — When Nobody Knows Whether It Was Sent Two legitimate endings for one attempt. The platform says which happened, and never guesses. v 1.0 · owner Integration Platform Architecture

Decisions

  • A submit that times out with no response is recorded as ambiguous, which is a fact, rather than as a failure, which would be a guess.
  • Whether to re-attempt is a per-route policy, not a platform-wide rule, and the policy applied is written onto the message so the decision is auditable.
  • A late receipt and a TTL expiry are both appended facts; whichever arrives first decides the terminal state, and neither can be overturned.

Assumptions

  • Most carrier protocols offer no idempotency key, so re-attempting risks a duplicate the carrier will also charge for.
  • Default policy: do not re-attempt on a route that cannot be queried. Explicitly overridable per route.

Risks

  • This is the view a reviewer should argue with: the default protects the recipient from a duplicate and accepts a silent non-delivery, and for some traffic classes that is the wrong way round.
◀  Per-Channel Pipelines All views Deployment  ▶
Solution Architecture v1.0 · Google Cloud · Integration Platform Architecture · 2026-10 · 22 views · 16 architecture decision records16-ambiguous-submit