Sending a message from the client to the service may be tricky because transport channels are not 100% available. Due to communication errors sending a message may fail. When the message delivery must be guaranteed we need to implement more complex delivery patterns. While this aspect is closely connected with messaging you can use these patterns with any kind of integrations. From the point of delivery guarantee for the message we can define three different levels:
- At most once or 0-1 delivery or Fire and Forget or QoS 0 in MQTT
- At least once or 1-n delivery or QoS 1 in MQTT
- Exactly once or 1-1 delivery or QoS 2 in MQTT
At most once
This is the simplest but most performant delivery pattern. There is no guarantee of message delivery. The client sends a message to the service with best effort while ignores any eventual error. On the other hand, service may or may not receive the message.
This scenario is the best case in situations when loosing few messages plays no role in the overall business process. Practical example is sending a temperature from the sensor few times per second while we just want to display the value on the dashboard.
At least once
This delivery pattern is more complex but guarantees a delivery of the message. The client keeps sending the message until successful. Because process of sending a message need to be durable it is important to store the transaction in a permanent storage. From the service perspective, message may be delivered multiple times.
This scenario is suitable in situations when multiple delivery is not a problem. Message should have an absolute character like setting a value. Relative character like adding a value is a problem when applied multiple times.
Exactly once
This is the most complex delivery pattern which guarantees exactly once delivery of the message. Like in previous scenario, the client keeps sending a message while not successful. The difference is in a way how the service handles multiple message delivery. The service builds a permanent store of received messages to detect already processed messages. The service processes the message only once.
While this scenario seems to be the most practical, the problem in complexity should be considered.