Thundering herd has evolved beyond the original definition, that happens. Sometimes terms even flip their meaning (like how "one bad apple" has flipped it's meaning, or how "pre-optimization is the root of all evil" as used these days isn't what the original author actually meant, but in this case I think most of the new usages fit the basic idea, which is a large amount of unusual traffic happens outside of normal usage patterns.

Fair point that terms like this can change meanings.

But this version absolutely does not fit the original, which had nothing to do with amounts of traffic.

It was a problem with kernel APIs: if N threads sleep waiting for an event on a socket (i.e. a thread pool), there was no way to wake up only one of them when a single msg arrived. They would all wake, all check if there was work to do, then all (but one) would go back to sleep. This is a behavioral flaw even in the case of next to no traffic (though it may not have an material effect).

The problem has been solved with better kernel APIs.

I initially heard of "thundering herd" in reference to the pattern where a server handling N requests for the same data may only need to run the data handling logic once to fulfill all of those requests.

For example, if I have a server with an endpoint that needs to make a request to a different service for some data, I don't want to make that request 10 times when my server receives 10 requests while the first request is being handled; all 10 of those incoming requests can be fulfilled by 1 outgoing request to the secondary service.

In that sense, it's very similar to what you described, but it's still likely one process handling the requests.

I'll admit that the author seemed to use "thundering herd" in reference to your server just suddenly receiving a lot of traffic, which is also different from the usage I was familiar with.

Please read the comment from user gilbetron appearing really close to yours, and my reply.

Ah sorry, didn't realize thundering heard was solved by newer kernels. I can remove all my exponential back off with jitter retry strategies.

Your exponential back offs were not a solution to the problem identified and named in the mid-90s. They might be valuable for some other problem.

Good thing the problem is solved then.