Retry and Backoff Strategies
This cluster centers on discussions about implementing retry mechanisms, exponential backoff, jitter, and handling transient failures in APIs and services during outages or errors. Commenters debate best practices, trade-offs like latency, and alternatives such as queues or idempotency.
Activity Over Time
Top Contributors
Keywords
Sample Comments
The page didn't mention retries, exponential back off, etc. Is there somewhere where it shows how that sort of thing is handled?
If only there was a simple way to exponentially limit your retries and back off a bit when the other side is constantly failing.
There is something inherently wrong with that - it's why exponential backoff exists.
If a client retries it’s not necessary for all 100 requests to be attempted again. The system could be designed to only repeat the unsuccessful operations.
The article mentions exponential retry periods for that.
Please share those reasons. The only one I can think of is false positives of temporarily down servers, which could be mitigated by timed retries.
In this case it seems like a retry will change this API from "completely broken" to "working again".
Errors are so common with these endpoints, not having retry out of the box just makes it harder to hack on which I think is against the spirit?
So nothing like automatic retries/backoff or queue failed requests?
aren't retry policies inherently compromising on "A"? they fail and cause things to be slow when they take effect