EIP Retry Patterns

Summary

Integration failures are common, various Retry patterns can be used in addition to the technology itself providing a retry mechanism. This page documents some of these Retry patterns.

Retry Patterns

The most common Retry patterns are:

1. Continuous Retry
2. Retry with/without Max number of attempts
3. Scheduled Retry with/without Max number of attempts
4. Scheduled Retry with/without Sliding Window with Max number of attempts
5. Exponential Backoff with/without Max number of attempts
6. Random Retry with/without Max number of attempts
7. Abort

Continuous Retry

In this EIP, a Process will continue to retry indefinitely. This retry design pattern is ideal in scenarios where consistency and resource consumption is of no concern. A Process communicating with a Sub-Process will continue to try in an endless loop.

do{
    try{
         // Execute Business Logic
       }
    catch
       {
         // Execute Business Logic
       }
while (true)

Retry Nth Times

This Retry method attempts to retry business logic nth times before aborting. This pattern should be used when the cost of retrying is expensive or the operation needs to be manually corrected. Some endpoints such as Stripe API Gateway enforce an nth number of retries before aborting to ensure service quality is not degraded for other consumers. Aborted processes should be logged and monitored.

Schedule Retry with Max Attempts

If a Process fails to complete, rather than simply trying again immediately; the retry is scheduled to execute at a later time. This retry attempts to solve issues where transient failures may have prevented an operation from successfully being completed. Together with enforcing a maximum retry count, a Process may attempt to schedule a retry every hour, ten times before aborting.

An alternative to this is to continuously retry based on a schedule without a maximum threshold count. The Rety policy will need to be manually aborted.

Schedule Retry Sliding Window with Max Attempts

This is similar to the scheduled retry, with the only difference being the next retry attempt is increased with a delay. For example; if a retry fails at 12:00 PM with the next scheduled retry set to 3:00 PM, the sliding window may update that time by 1 hour with the next retry attempt being 4:00 PM. This may continue until the retry is manually aborted or the maximum number of attempts is reached.

Exponential Backoff with Max Attempts

The Exponential Backoff retries based on a set interval, however with each failed attempt additional time is added to the next retry. For example, if an order failed to process at 12:00 PM, the Exponential Backoff rule may state that the next retry will take place 30 minutes later. The time delay between retry attempts is exponential. In the Exponential Backoff, there is no schedule reties. The business logic determines when the next retry takes place with additional time added to every failed retry attempt.

Random Retry

The Random Retry pattern attempts to retry a failed processing at a random interval. This interval is completely random, for example, the next retry might be 2 minutes later or 30 minutes later. The Random Retry pattern is a good design to use where eventual consistency is acceptable.

Abort

In some instances, it is better to abort than retry than to try continuously. This may be because the retry may be expensive or the retry operation may cause data loss or inconsistencies.