[j1elo]

There's a subtle insight that could be added to the post if you consider worth it, and it's something that's actually there already, but difficult to realize: Clients in your simulation have an absolute maximum number of retries.

I noticed this mid-read, when looking at one of the animations with 28 clients, that they would hammer the server but suddenly go into wait state, without apparent reason.

Later in the final animation with debug mode enabled, the reason becomes apparent for those who click on the Controls button:

Retry Strategy > Max Attempts = 10

It makes sense, because in the worst case when everything goes wrong, a client should reach a point where it desists and just aborts with a "service not available" error.

[samwho]

You know, I hadn't actually considered mentioning it. Another commenter brought it up, too. It's so second nature I forgot about it entirely.

I'll look about giving it a nod in the text, thank you for the feedback. :)

[fiddlerwoaroof]

Exponential retries can effectively have a maximum number of requests if the gap between retries gets long enough quickly enough. In practice, the user will refresh or close the page if things look broken for too long.

[marcosdumay]

Oh, please don't do that.

Unbounded exponential backoff is an horrible experience, and improves basically nothing.

If it makes sense to completely fail the request, do it before the waiting becomes noticeable. If it's something that can't just fail, set a maximum waiting time and add jitter.

[fiddlerwoaroof]

I think decoupling retry logic from the “there’s something wrong” UI ends up being a better experience than tieing the UI state to the details of network retries. (For one thing, it gives you a chance to fix the “everything is broken” UI without any action on the user’s part.