Retries

This page describes some best practices to implement retries of failed API calls against our platform.

Use exponential backoffs

To issue retries in case of the described HTTP 429: Too many Requests we suggest implementing a retry mechanism based on an exponential backoff algorithm.

This approach might sound like over-complicating things. This is, in fact, not the case.

Implementing such mechanisms adds substantial resilience to the system as your client is aware and able to cope with the situation that, for a brief period of time, the functionality of a remote service is not available. This could and will - rarely, but still - happen in any distributed system!

For developers, there are some libraries available that have already implemented the exponential backoff. Here are some examples:

Library	Language	Link
Resilience4J	Java	https://github.com/resilience4j/resilience4j
exponential-backoff	Node	https://www.npmjs.com/package/exponential-backoff

Best practice: Retries for other HTTP status

Once you have an exponential retry mechanism in place, it makes sense to also leverage this mechanism for the following HTTP status codes:

• 500 Internal Server Error

• 502 Bad Gateway

• 503 Service Unavailable

• 504 Gateway Timeout

• 408 Request Timeout