Delivery Guarantees & Ordering

The Three Delivery Guarantees

At-Most-Once — The message is delivered zero or one times — never twice. The broker fires and forgets. If the consumer crashes before processing, the message is lost forever.

• Use when: Occasional message loss is acceptable. Low-priority telemetry, non-critical metrics. Fastest and simplest.

At-Least-Once — The message is guaranteed to be delivered one or more times — it will never be lost. The broker retains the message until the consumer explicitly acknowledges it. If the consumer processes the message but crashes before acknowledging, the broker redelivers it.

• Use when: Data loss is unacceptable. The vast majority of production systems.
• Critical requirement: Consumers must be idempotent — processing the same message twice must produce the same result as processing it once. A deduplication key (e.g., a unique message_id) stored in a database is the standard pattern.

Exactly-Once — The message is processed precisely once — never lost, never duplicated.

• The reality: True exactly-once delivery at the network level is a myth. What modern systems offer is exactly-once processing semantics — achieved either through idempotent consumers (at-least-once + deduplication) or transactional messaging.

Ordering Guarantees

• No ordering guarantee: Messages may arrive in any order. Simple and fast. Acceptable for most independent tasks.
• FIFO ordering: Messages are delivered in the order they were sent. Required for a user's transaction history, state machine transitions, or any case where event sequence matters. Typically limited to a single partition or queue — cross-partition ordering is impractical at scale.

Do not assume ordering unless you explicitly need it. Most workloads have no ordering dependency.