Timeout & Retries – learnings
January 19, 2022 Leave a comment
- As an API developer, my first goal is to provide robust client side implementation for request timeout and it is different from connection timeout. Both too high or too low is generally considered bad. It should be based on your promised SLA on latency. You may eventually end up tuning connection and other underlying platform level configurations that are optimal for your use case.
- Retries are my client’s unintentional punitive actions against you for violating or not improving SLA. This outcome becomes severe when your service starts failing under load and the retries increases exponentially though there is no point of beating a dead horse, hence comes backoff.
- Another important point is about cumulative retries from chain of services. You might be having complete useless timeouts as one of the way down dependency does not even honour you min timeout.
- Exponential backoff is good to reduce contention but does not do anything to distribute the incoming traffic into equal time slices. This is why the leaky bucket or fixed window or the token bucket algorithm performs poorly on edge cases. On the other hand jittered backoff helps to shape traffic using randomness and it could seen in sliding window rate limiting.
- Be extreme careful not to degrade customer experience while using Jitter, you do not want to lose them with delays but rather give them frustration free simple in and out experience.
- Another important API property to pay attention is idempotent. If you are using any identifier based approach to identify duplicate requests then be sure to include that in retry request.