Delivery Semantics

Imagine you're building an event-driven system where a billing service needs to process payments whenever a user clicks "Checkout." You drop the "Process Payment" event into a message broker like Kafka or RabbitMQ, and the billing service picks it up.

But networks are flaky. Servers crash. What happens if the message gets lost in transit? What if the billing service crashes right after receiving the message but before charging the credit card? Or worse, what if it charges the card but crashes before telling the broker, and the broker sends the message again, double-charging the user?

This is what delivery semantics covers — the guarantees a messaging system provides about how many times a message will be delivered.

There are three types:

1. At-most-once
2. At-least-once
3. Exactly-once

At-Most-Once (Fire and Forget)

With at-most-once delivery, a message is delivered zero or one time. The system tries to deliver it, but if something goes wrong, it drops the message and moves on.

Think of a paperboy throwing newspapers from a bicycle. If the paper lands in a puddle, he doesn't go back. You get the paper at most once.

How it works: The producer sends the message and doesn't wait for an acknowledgment. The consumer receives the message, and the broker deletes it from the queue before the consumer even finishes processing.

When to use it: Use this when data loss is acceptable, but high throughput and low latency are critical.

• IoT sensor data: If a temperature sensor sends a reading every second, missing one reading doesn't matter. The next one arrives in a second.
• Video streaming metrics: Sending a ping every 10 seconds to calculate rough viewer counts. A missed ping is irrelevant.

At-Least-Once (Guaranteed Delivery)

With at-least-once delivery, the system guarantees the message will be delivered and processed, but in failure scenarios it might be delivered more than once.

Think of certified mail. The postman hands you a package, but won't leave until you sign. If you take the package but refuse to sign, he comes back tomorrow and hands you another copy until he gets the signature.

How it works: The broker sends the message to the consumer but keeps a copy. The consumer processes the message and then sends an ACK back to the broker. Only then does the broker delete the message. If the consumer crashes before sending the ACK, or if the ACK is lost in transit, the broker redelivers to another consumer.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

At-least-once delivery is the standard guarantee in most message brokers (SQS, RabbitMQ, Kafka). The broker keeps a copy of the message and only deletes it after receiving an explicit ACK from the consumer. If the consumer processes the message but crashes before sending the ACK — or if the ACK is lost in transit — the broker assumes delivery failed and redelivers to another consumer. This means the same message can be processed twice. Every consumer in an at-least-once system must be idempotent: processing the same message twice must produce the same outcome as processing it once. The standard approach is to check a database for the event ID before acting, and write the ID as part of the same transaction as the business logic.

1 / 10.5×1×2×3×Playground

At-least-once — broker keeps message until ACK, redelivers on crash

When to use it: This is the default for most systems (SQS, RabbitMQ). Use it when you cannot lose data, but your consumer must be idempotent — processing the same message twice must have the same effect as processing it once.

• Ride status updates: If the app receives "driver has arrived" twice, it just shows "arrived" both times. No harm done.
• Database updates: If the message says UPDATE users SET status = 'active' WHERE id = 5, running it twice is harmless.

Exactly-Once (The Hardest Problem)

With exactly-once delivery, the message is guaranteed to be delivered and processed exactly one time. No data is lost, no duplicates are processed.

Exactly-once is hard to achieve because it requires coordination between the producer, the broker, and the consumer. It's theoretically impossible to guarantee over an unreliable network (the Two Generals' Problem), but systems approximate it using at-least-once delivery plus transactional deduplication.

Kafka achieves "exactly-once semantics" (EOS) by assigning sequential IDs to messages and using transactional commits. If a producer retries sending a message, Kafka sees the duplicate ID and drops it. On the consumer side, the offset (tracking what was read) and the output are updated in a single atomic transaction.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

Exactly-once semantics are built on top of at-least-once delivery plus transactional deduplication. The producer assigns a unique, stable ID to every message. The broker may still deliver the message more than once (due to retries). The consumer checks a dedup table before acting: if the event ID has been seen before, it skips the message and ACKs normally. If the ID is new, it processes the message and records the ID in the same database transaction as the business operation — making the check-and-process atomic. This fakes exactly-once at the application layer. Kafka adds native exactly-once semantics (EOS) using producer idempotency and transactional commits for consumers that read from and write to Kafka topics.

1 / 10.5×1×2×3×Playground

Exactly-once — dedup table prevents duplicate processing, check-and-act is atomic

When to use it: Use this when operations are strictly non-idempotent and absolutely cannot happen twice, and you are willing to pay a performance cost for coordination.

• Financial transactions: You cannot process a "$100 withdrawal" event twice.
• Analytics billing: Charging an advertiser per ad click. A duplicate message means double-billing.

Comparing the Three

Summary

When designing event-driven systems, you must explicitly choose delivery semantics based on business needs. At-most-once is fast but drops data. At-least-once is the industry standard but requires idempotent consumers. Exactly-once is complex and slow, but necessary for strict financial or transactional workloads where duplicates are catastrophic. In practice, most systems use at-least-once delivery and invest in idempotency rather than paying the overhead of exactly-once coordination.