Handling Rate Limiting

When interacting with APIs, adhering to imposed rate limits is crucial to ensure smooth operation and avoid encountering HTTP 429errors (Too Many Requests). iProov has a rate limit of “TPS limit as per your contract” Transactions Per Second (TPS) per Service Provider. This limit is in place to ensure a consistent and reliable service for all of our customers. If you anticipate needing a higher rate limit, please contact us in advance and we can discuss increasing it for you. Accurate volume estimations from customers are essential for iProov to provide the best possible service.

The document discusses the use of a backoff mechanism to mitigate the risk of exceeding a TPS limit and encountering subsequent HTTP 429 errors. The backoff mechanism introduces a delay between consecutive authentication attempts, reducing the likelihood of exceeding the TPS limit. There are several backoff mechanisms available, each with its own characteristics and suitability for different system requirements. Two commonly used mechanisms are exponential backoff and linear backoff.

Exponential Backoff

Exponential backoff is a widely utilized technique where the delay duration increases exponentially after each failed attempt. For instance, an initial delay of 1 second might be doubled to 2 seconds after the first failed attempt, then quadrupled to 4 seconds after the second failed attempt, and so on. This strategy results in a rapidly increasing delay period, which effectively discourages excessive retry attempts and helps distribute the load over a longer time frame.

Linear Backoff

Linear backoff takes a simpler approach by linearly increasing the delay duration with each failed attempt. For example, the delay might be incremented by a fixed amount, such as 1 second, after each unsuccessful try. While it provides a consistent and predictable delay pattern, linear backoff may not be as efficient as exponential backoff in preventing consecutive 429 errors when the rate limit is strict.

The choice of backoff mechanism depends on various factors such as the system’s load characteristics, the severity of rate limiting, and the desired response time. Exponential backoff is generally preferred when the rate limit is strict and minimising the number of HTTP 429 errors is critical. On the other hand, linear backoff may be more suitable for systems that can tolerate a higher rate of HTTP 429 errors or require a more predictable delay pattern.

A backoff mechanism can prevent exceeding the TPS limit during simultaneous user authentication, ensuring a reliable and efficient process.

Rate Limit - Endpoints:

IMPORTANT: The TPS Limit does not impact at the SDK level, meaning once the user journey has started in the app it will complete successfully.

Example implementationn

Pseudo-code

define max_retries
define initial_delay

function retry(operation, max_retries, initial_delay)
    attempt <- 0
    delay <- initial_delay
    while attempt < max_retries do
        try
            operation()
            return
        catch
            attempt <- attempt + 1
            sleep delay
            delay <- delay * 2
    end while
end function

Exponential backoff increases the time between retries to prevent overloading the system.