Seems like the proper fix would have been to remove the file from the server when they realized the increased traffic. Then clients would just fail to check the update each time and not tie up bandwidth.

Wish people would actually do things like this more often.

Plenty of things (like playstation's telemetry endpoint, for one of many examples) just continually phones home if it can't connect.

The few hours a month of playstation uptime shows 20K dns lookups for the telemetry domain alone.

Why not just use http retry-after? then you can use middleware/proxy to control this behavior. Downside here is that system operation becomes more opauqe and fragmented across systems.

Because the client in this case is not a browser.

There is a standard HTTP header for this: Retry-After.

Could you expend on what is an "override backoff" ?

The client might have a feature to retry certain failures, and it’s using a particular rate, probably not retrying n times one right after the other in rapid succession. This is called backoff.

The server can return an override backoff so the server can tell the client how often or how quickly to retry.

It’s nice to have in case some bug causes increased load somewhere, you can flip a value on the server and relieve pressure from the system.

Exactly. Without going too deep into the architecture, the clients are sending data to the backend in real time, but often that data is not actionable during certain periods, so the backend can tell the clients to bundle the data and try again after a certain amount of time, or just discard the data it's currently holding and try again later (i.e. in 5/10/n seconds)

Thanks for your responses. I’m used to "throttle", seems to be a synonym right?

sure, you could say throttle.

Presumably the back end could tell the client not to check again for some amount of time. Sounds similar but different to cache TTLs, as those are passive.