At-Most-Once Delivery
The symmetric opposite of at-least-once. Acceptable only for flows whose loss has no business impact.
Problem
Some EDI flows carry non-critical information: intermediate IFTSTA statuses over IoT networks, telemetry events from logistics sensors, hourly KPIs. Imposing at-least-once + deduplication on these flows adds cost and latency for no benefit — a "truck en route" status lost has no major business impact if the next one arrives.
Forces
- Very high volume on IoT/telemetry flows; deduplication is expensive.
- Loss tolerance demonstrated by business usage — a lost status is replaced by the next one.
- Low latency matters more than completeness.
- Retry would amplify the outage — when the partner is down, thousands of sensors must not all retry.
Solution
Set up a fire-and-forget send policy: UDP or Kafka acks=0,
no retry on network failure, no receiver-side deduplication. Loss is
documented as acceptable in the partner agreement; SLAs are expressed
as "X% of events received under Y seconds", not "zero loss".
EDI implementation
In regulatory EDI (CUSDEC, INVOIC, ORDERS, PAYMUL) at-most-once is forbidden: losing a declaration or an order has business or
legal impact. The semantics is reserved for secondary flows: GPS
positions from IFTSTA sensors, pre-event telemetry, internal hub
indicators. On Kafka, the configuration is acks=0 on the
producer + auto.offset.reset=latest on the consumer. On
HTTP, a POST with no retry body and no backoff is accepted.
Anti-patterns
- At-most-once on an INVOIC or ORDERS. Severe integration fault — a lost order is an incident.
- Silent configuration. The semantics must be explicit in the partner agreement, not a tool default gone unnoticed.
- Mixing semantics on the same channel. All orders on the same lane as telemetry produces an immediate observability debt.
- Counting operational success of an at-most-once flow as zero loss. The SLA must publish the expected loss (e.g. 0.1% monthly).
Related patterns
- At-Least-Once — the reliable counterpart, default semantics.
- Event Message — the message style most often in at-most-once.
- Dead Letter Channel — typically absent for at-most-once (nothing to reprocess).
Sources
- Kleppmann M. — Designing Data-Intensive Applications, chap. 11, delivery-semantics table. dataintensive.net
- Apache Kafka — Producer configuration,
acksparameter (0/1/all). kafka.apache.org/documentation/#producerconfigs_acks - RFC 8085 — UDP Usage Guidelines (IETF, 2017), the canonical reference for network fire-and-forget. rfc-editor.org/rfc/rfc8085