sroussey 2 hours ago | parent | next [-]

Yes, exponential back off and jitter are the first things to work on, and good if you don’t have a better signal (like loss of network).

Also, a simple signal status server or queue system helps to keep global state such that everyone doesn’t retry all at once.

If you have a central error rate server you can skip your retry based on the error rate (100% error rate, don’t retry, etc).

▲

anonymars 2 hours ago | parent | prev [-]

https://devblogs.microsoft.com/oldnewthing/20051107-20/?p=33...

▲

applfanboysbgon 2 hours ago | parent [-]

This is trading a good developer experience for a bad user experience. There are situations where it makes sense to force manual retry, but there's no reason to apply one universal rule to all possible situations. Lack of considering nuance for your situation is just intellectual laziness.

▲

anonymars an hour ago | parent [-]

My point was that just throwing exponential backoffs at the retry problem is not a magic solution

I don't follow how being cautious about avoiding multiplicative layers of backoffs is trading a good developer experience for a bad user experience. The described situation is an awful user experience. Simply adding a retry and calling it a day sounds like the easy developer experience at the expense of the user experience

▲

applfanboysbgon an hour ago | parent [-]

> The described situation is an awful user experience

Sure, the worst case scenario is. 99.9999% of the time, a transient error will actually just work on the first or second auto-retry and save your users the effort of paying attention and manually retrying things. This is especially prudent for background tasks where the failure may not be noticed right away; coming back to something fire-and-forget 30m later to see it never tried to finish is not a good user experience.

> My point was that just throwing exponential backoffs at the retry problem is not a magic solution

Nobody said it was. In fact, I suggested the exact opposite - a proper solution takes dev effort. Adhering to an iron rule of "just make them manually retry" is throwing your hands up and not even trying to solve the problem because laziness is convenient.

	▲	anonymars 39 minutes ago \| parent [-]
		> Nobody said it was I responded to a post that merely linked to the Wikipedia article for exponential backoff (in response to "I'd be interested to hear other strategies in [protecting against retry storms]") The original article is precisely about the degenerate case and the difficult work of dealing with it > This approach works for transient or low-rate failures. However, during moderate or severe degradation, it becomes counterproductive. Aggressively retrying against an already struggling service increases load, accelerates failure, and amplifies retry traffic across upstream dependencies. What begins as a localized outage can quickly escalate into a stack-wide incident—ultimately degrading, or in the worst case, completely breaking, the end user experience.