At-Most-Once Delivery

At-most-once delivery is the quiet cousin of messaging guarantees: each message shows up once at best, and sometimes not at all. No duplicates—that part sounds nice until you realize the flip side is loss. IBM MQ can be configured and used in ways that lean at-most-once, especially with non-persistent messages, auto-commit gets, or committing the removal of a message before your business logic finishes. Beginners chasing speed sometimes accidentally build at-most-once payment flows and only discover the gap during disaster recovery. This page defines the semantic, contrasts it with at-least-once and exactly-once processing, walks through dangerous get/commit orderings, relates fire-and-forget and telemetry patterns, and shows how to document acceptable loss with operations and auditors.

Definition and Mental Model

In integration textbooks, three guarantees form a triangle. At-most-once sacrifices reliability to avoid duplicate side effects. At-least-once sacrifices duplicate-freedom to avoid loss. Exactly-once processing is achieved in application logic on top of at-least-once transport. MQ does not offer a broker switch labeled AT_MOST_ONCE, but your persistence choices, syncpoint usage, and when you commit a get produce the effective semantics your business experiences.

Non-Persistent Messages and Loss

When the producer uses MQPER_NOT_PERSISTENT and the queue manager suffers a hard failure, messages that were not yet delivered may never appear after restart. That is at-most-once from the perspective of survival: you will not get two copies from redelivery after a crash because the message may be gone entirely. Controlled operations still plan capacity as if loss can happen on any unclean shutdown. Pair non-persistent with metrics where the next sample supersedes the last.

The Dangerous Get-Commit-Process Order

A persistent queue does not save you from at-most-once processing if the consumer removes the message too early. Pattern: MQGET with no syncpoint (or immediate commit of the unit of work), message leaves the queue, application processes, crash mid-flight. MQ cannot redeliver what it no longer holds. Operations sees a successful depth decrease and a failed business row. Training materials emphasize: under syncpoint, process, then MQCMIT together with database work when coordinating; or accept at-least-once and make handlers idempotent.

Fire-and-Forget and Notifications

Fire-and-forget producers put a message and close the connection without waiting for application acknowledgment beyond the MQPUT completion. Combined with non-persistent delivery mode in JMS, this is a common at-most-once path for we tried to notify UI refresh style events. If the notification must arrive, use persistent messages and design the consumer for at-least-once with idempotency or deduplication.

Pub/Sub and At-Most-Once

Non-durable subscriptions in JMS disappear when the subscriber disconnects—unreceived messages are not held for that subscriber. That behaves like at-most-once for that consumer even though the topic retained other messages for durable subscribers. IBM MQ topics with durable subscriptions shift toward holding messages until consumed, moving the guarantee toward at-least-once for those subscribers.

Comparing to At-Least-Once

• At-most-once: simpler consumer, no duplicate handling, acceptable loss.
• At-least-once: persistent messages, syncpoint, backout and retry, need idempotency.
• Choose at-most-once only when product owners sign loss scenarios in writing.

Monitoring At-Most-Once Flows

1. Tag interfaces in your catalog as LOSS_TOLERANT.
2. Never mix LOSS_TOLERANT and FINANCIAL on the same queue without strict routing.
3. Dashboard depth drops during outages may mean loss, not successful processing.
4. Disaster tests: kill queue manager during load and measure business gap.

Tutorial: Safe vs Risky Consumer Pseudocode

1
2
3
4
5
6
7
8
9
10
11
Risky (at-most-once processing on persistent queue):
  GET message
  COMMIT get immediately
  PROCESS message  <- crash here = lost forever
 
Safer for business data (at-least-once):
  BEGIN syncpoint
  GET message
  PROCESS message
  UPDATE database
  COMMIT syncpoint  <- all or nothing; on failure BACK -> redelivery possible

Explain Like I'm Five: At-Most-Once

You throw one paper airplane with today's joke written on it. If the wind blows it away before your friend reads it, you do not throw a second copy—they might get zero jokes or one joke, never the same joke twice from you. That is fine if the joke was optional; it is not fine if the paper was their homework grade.

Practice Exercises

Exercise 1: Classify

Label each as at-most-once friendly or not: stock trade, chat typing indicator, monthly invoice, radar blip every 2s.

Exercise 2: Fix the Consumer

A team commits gets before calling a slow REST API. Propose a syncpoint pattern without duplicates in the happy path only—is that enough?

Exercise 3: DR Test

Non-persistent depth 10,000, hard kill QM. What do you tell the business about messages in flight?

Frequently Asked Questions

Test Your Knowledge