Retry vs. Multidispatch

It is common in a distributed system that not 100% of the async calls are executed successfully for various reasons. For example, temporary network issues, request to a service that is going through a redeployment stage, timeouts, etc.
In this article, I would like to discuss 2 approaches on how you can increase the chances that your async calls will be executed successfully.

Retry
With this approach, we can choose a strategy in which if a call is returning an error we will try again to execute it X amount of times again in a sequence.
There are few ways of running a retry, I will list a few of them:
1. Run a retry immediately after the execution of a failed call.
2. Wait X amount of time before running a retry after the execution of a failed call.
3. Wait an increasing amount of time for each of the retries after the execution of a failed call.

Pros:
1. No overloading of the target service. We are doing a single request in each of the retries.
2. Because we can introduce delays between the retry calls we are increasing the chances that the target service or the network is healthy again.
3. Can be used for read and write operations.

Cons:
1. Running retries will cause latency for the original call to your service.

Multidispatch
With this approach, for every request that you are doing to a third-party service, you will actually run multiple requests. The first call that returns a successful answer will resolve the original request and the other replays will be ignored. You can choose the number of simultaneous calls you want to run thus increasing the chance of successful replay.

Pros:
1. Fast replay to the original caller of the service as all calls are being executed in parallel.

Cons:
1. Adding an extra load on the target services.
2. For temporary network issues all requests will fail as there is no delay between the calls.
3. You can only do immutable operations (such as read).

Usecases
At first glance, it seems like the Retry strategy is better than the Multidipatch approach. But, as it usually happens in real life, it depends on your needs. If you have a heavy read application when the latency is your number one KPI then you probably want to choose the Multidispatch approach as it will guarantee the best performance.
If you are ok with increasing the latency of your replies and your main KPI is increasing the chances of successful execution of the call then you probably want to choose the Retry mechanisem.

Implementation and usage:
If you would like to try on or both of the above strategies you can do it with the utils-decorators library which implemented both and it can be used in both web and node environments. You can find an example in the following links: Multidispatch & Retry.