Retries

This document outlines the recommended approach for implementing retries for failed API calls to the fulfillmenttools platform.

Exponential backoff algorithm

It is recommended to implement a retry mechanism based on the exponential backoff algorithm for requests that fail with an HTTP 429 Too Many Requests status. This strategy progressively increases the wait time between retries to avoid overwhelming the service. For a detailed explanation, refer to the article on exponential backoff.

A flowchart illustrating the exponential backoff process. It shows an initial request, a failure response, a short wait, a retry, another failure, a longer wait, and a final successful retry.

Implementing this type of retry mechanism adds substantial resilience to an integration. It ensures the client application can cope with brief periods of service unavailability, which can occur in any distributed system.

The following libraries provide pre-built implementations of the exponential backoff algorithm:

Library	Language
Resilience4J	Java
exponential-backoff	Node

Retries for other HTTP status codes

This retry mechanism can also be leveraged for other transient server-side errors. It is beneficial to apply the same logic for the following HTTP status codes:

• 500 Internal Server Error

• 502 Bad Gateway

• 503 Service Unavailable

• 504 Gateway Timeout

• 408 Request Timeout