A security analyst is troubleshooting a custom integration that interacts with a cloud-based security service. The integration intermittently fails with HTTP 429 'Too Many Requests' errors, indicating that it is exceeding the service's rate limits. The service documentation suggests implementing an exponential backoff strategy for retries. Which approach is most suitable for implementing exponential backoff in the custom integration?
- AIncrease the `command_timeout` parameter in the integration configuration.
- BUse `demisto.sleep()` with a progressively increasing delay after each failed attempt, up to a maximum number of retries.
- CDisable rate limiting on the cloud-based security service.
- DHardcode a fixed delay (e.g., 5 seconds) between all retry attempts.
Show answer & explanationAnswer & explanation
Correct answer: B. Use `demisto.sleep()` with a progressively increasing delay after each failed attempt, up to a maximum number of retries.
Exponential backoff involves increasing the wait time between retry attempts after successive failures. Using `demisto.sleep()` (which is a wrapper for `time.sleep()` in XSOAR) with a progressively increasing delay (e.g., 2, 4, 8 seconds) and a defined maximum number of retries is the standard and most effective way to implement this strategy, preventing overwhelming the API and allowing it to recover.
Why the other options are wrong
- A. `command_timeout` defines the maximum execution time for a command, not the retry logic for API calls within that command.
- C. Disabling rate limiting on the external service is typically not possible or desirable, as it protects the service from abuse and overload.
- D. A fixed delay does not adapt to the server's load and may still lead to excessive retries if the server is heavily loaded, or unnecessary delays if it recovers quickly.
Exponential Backoff
A retry strategy where the delay between successive retry attempts increases exponentially, helping to alleviate server load and recover from transient errors.
- Increases wait time after each failed attempt.
- Reduces load on the API server.
- Used for rate limiting and transient network errors.
- Requires a maximum retry limit to prevent infinite loops.
Memory trick: When the API says 'too fast', slow down exponentially, then try again.