Delivery Guarantees: At-Least-Once

At-least-once delivery means that the broker will ensure that a produced event is delivered at least once (still obvious, right?). What this means is that all consumers can read the event, and the broker will continue to deliver it to any other consumer until such a time as a consumer acknowledges it has processed the event. It’s at-least-once delivery, so there’s a possibility that an event might be delivered more than once.

The Producer must wait for acknowledgment from the broker that an event is received. If the broker doesn’t acknowledge successful receipt, then the Producer will repeatedly try until it does. This adds a throughput overhead, which will impact performance and scalability. However, this also ensures an event is received by the broker as is required for the at-least-once delivery.

Any Consumer that reads the event that crashes or fails before it completes its work will not be able to acknowledge successful delivery. Therefore, the broker will continue allowing Consumers to read the event until it is acknowledged. Because of this, it’s entirely possible that events are consumed more than once but at least once. Overall, this is a burden on performance on both sides of the event, but hopefully, it’s clear that this delivery guarantee is suited for unacceptable data loss in a system. At the same time, the Consumers must account for the possibility of duplicate event processing.

Code example—Producer

For the Producer to ensure the event was received by the broker, it must examine the delivery state of the ProduceAsync() call. For completeness, it should also catch any exception that can occur and treat that as a failure.

We’ll wrap the ProduceAsync() call in a do {...} while(...) loop, and use the delivery result (or caught exception) to decide whether the delivery was successful or whether it needs to be attempted again.