Delivery Guarantees: At-Most-Once

Event brokers typically provide several methods of delivery guarantees. Through the interfaces used to both produce and consume an event (API or SDK), the event broker can ensure how messages are delivered:

• At-most-once delivery

• At-least-once delivery

• Effectively once delivery

The delivery method we choose for any given event depends on which benefit we want to achieve. As we explore each delivery method, we will explore examples that highlight the benefits and trade-offs of each.

At-most-once delivery

At-most-once delivery means that the broker will ensure that a produced event is only delivered at most once (obvious, right?). What this means is that as soon as the first consumer processes the event, the broker will not deliver the event to any other consumer. It’s at-most-once delivery, so there’s a possibility that an event will never be delivered:

• First, the producer doesn’t wait for acknowledgment from the broker that an event is received. It will fire and forget. This is fantastic for performance and throughput. However, this also means the broker might never successfully receive the event. Yet the producer will just carry on as if it did.

• Second, a consumer that reads the event might crash or fail before it completes its processing. The broker is not aware of this failure, so it will assume success and not serve the same event to any other Consumer. Again, this is great news for performance, but hopefully, it’s clear that this delivery guarantee is only suited for acceptable data loss in a system.

Code example—Producer

We want to ensure that the Producer is sending a message only once. If the Producer crashes or the broker fails to receive the message, the Producer should not retry sending the event. Either it sends once or not at all.

Looking at the Send() method, we can see this behavior is already in effect without making any more changes.