When many clients see the same failure, they can all retry together. A fixed five-second delay may create another traffic spike five seconds later. This pattern can repeat even when the original service is recovering.
A retry policy can use backoff, which increases the delay after repeated temporary failures, and jitter, which adds variation between callers.
Keep the policy understandable
Choose a starting delay, a maximum delay, a maximum number of attempts, and a total time budget. The random part should spread work without making one listener wait indefinitely.
Respect a documented server retry instruction where one is provided. Do not use randomization to ignore a minimum waiting period. Authentication and validation errors usually need a changed request or user action, not a longer automatic retry sequence.
Put the policy in one client layer. If the browser, your server, and a background library each retry three times, one user action can cause far more attempts than the team expects.
Test a group, not one request
Create several controlled clients that fail at the same moment. Record when they retry. Their attempts should spread across a reasonable interval rather than form a second synchronized wave.
Then let the fixture recover. Confirm that the clients stop retrying once they receive a valid result. Cancel a few actions while they are waiting and verify that those requests do not return later without a user need.
Backoff is a pressure-control tool, not a cure for every error. Combine it with request limits, good caching, and a clear failed state. The listener should keep control of the task even while the integration is trying to recover.