Does it make sense to route every third-party API call through RabbitMq to use its dead-letter mechanism?

Question

For example, we want to pass some of our information to third-party API. We can't rely when this API would go down i.e. network error. So, we have two choices:

1. Log failures of the request being pushed in this API and try pushing them through some scheduled job - Issue is what if some of these requests failed due to API being down, we need to repush these failed requests too and this would go on an on.
2. Use something like Rabbitmq dead letter mechanism- You can use its retrial mechanism for failed requests but this adds to maintenance and what if it fails even after multiple dead-letter retrials?

How should we deal such third API processes and push the failed requests again?

Answer 1

So, RabbitMQ dead-lettering is not the same thing as a negative acknowledgement, though they can be related.

The scenario you are describing (assuming that I understand it correctly- your description is very abstract) is a fairly common situation, and can be described by the following sequence of events:

1. Processor takes message from queue
2. Processor attempts to process message
3. Processor fails to process message
4. ?

The question is what to do at step 4. In many applications, step 4 is to drop the message. However, RabbitMQ allows for the use of negative acknowledgements in this situation, which tell the broker that the message could not be processed. The broker, in turn, can place the message back at the head of the queue. There is nothing to stop the same processor from picking up the message again and attempting to process it if this happens, so this should be used when the failure condition is temporary (i.e. a problem with the processor, not the message itself).

Your application processing logic would need to decide when it makes sense to pull messages from the queue and attempt to process them. For example, it might make sense to wait a pre-determined period of time, or it may be wise to poll the 3rd party API until it comes back up. What you do here is up to you.

Dead-Lettering

Now, when you reject a message (basic.nack), you can control whether RabbitMQ dead-letters the message by specifying requeue=false. If requeue is false, then the message will be dead-lettered (or dropped, if there is no dead letter exchange configured).

A dead-letter queue is just that - it's a place where messages go to die. As a general rule, it should never make sense to connect your ordinary processors to this queue because, by definition, the reason messages were there in the first place is that they could not be processed- ever. So, if you intend for the condition to be temporary (i.e. a down server), requeue the message and stop processing more messages until the condition is resolved. If, on the other hand, there is a problem with the message, then by all means dead-letter it.