# What is Backoff For?

DevFeed: [What is Backoff For?](<https://devfeed.tech/articles/what-is-backoff-for-12523.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2022/08/11/backoff.html>)

Author: Marc Brooker

Published: 2022-08-11T00:00:00Z

Content type: article

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [client](<https://devfeed.tech/topics/client.md>), [servers](<https://devfeed.tech/topics/servers.md>), [systems](<https://devfeed.tech/topics/systems.md>), [Time Series](<https://devfeed.tech/topics/time-series.md>), [Network](<https://devfeed.tech/topics/network.md>)

Tags: [blog](<https://devfeed.tech/tags/blog.md>), [blog-post](<https://devfeed.tech/tags/blog-post.md>), [network](<https://devfeed.tech/tags/network.md>), [operational](<https://devfeed.tech/tags/operational.md>), [policy](<https://devfeed.tech/tags/policy.md>), [recovery](<https://devfeed.tech/tags/recovery.md>), [servers](<https://devfeed.tech/tags/servers.md>), [systems](<https://devfeed.tech/tags/systems.md>), [time-series](<https://devfeed.tech/tags/time-series.md>)

## AI overview

This article explains that exponential backoff and jitter help manage short overload spikes by spreading requests over time and reducing client-server chatter. During sustained overload, backoff is useful only when it reduces the total work sent to a service; merely delaying requests from many independent clients does not reduce load. The article also warns that retries can amplify service work and should be controlled with an appropriate retry policy, such as token buckets.

## Source excerpt

What is Backoff For? Back off man, I'm a scientist. Years ago I wrote a blog post about exponential backoff and jitter, which has turned out to be enduringly popular. I like to believe that it's influenced at least a couple of systems to add jitter, and become more stable. However, I do feel a little guilty about pushing the popularity of jitter without clearly explaining what backoff and jitter do, and do not do. Here's the pithy statement about backoff: Backoff helps in the short term. It is only valuable in the long term if it reduces total work. Consider a system that suffers from short spikes4 of overload. That could be a flash sale, top-of-hour operational work, recovery after a brief network partition, etc. During the overload, some calls are failing, primarily due to the overload itself. Backing off in this case is extremely helpful: it spreads out the spike, and reduces the amount of chatter between clients and servers. Jitter is especially effective at helping broaden spikes. If you want to see this in action, look at the time series in the exponential backoff and jitter post. Now, consider a long spike of overload. There are two cases here. One is where we have a large (maybe effectively unlimited) number of clients, and they're independently sending work. For example, think about a website with a million customers, each visiting it about once a day. Each client backing off in this case does not help, because it does not reduce the work being sent to the system. Each client is still going to press F5 the same number of times, so delaying their presses doesn't help. The other is where we have a smaller number of clients, each sending a serial stream of requests. For example, think of a fleet of workers polling a queue. Each client backing off in this case helps a lot because they are serial. Backing off means they send less work, and less is asked of the service1. That may sound like a subtle distinction, but the bottom line is this: does backoff actually