Credit-Based Flow Control
A scheme where a receiver grants the sender a budget of bytes or messages it may transmit, replenished as the receiver consumes.
The mechanism underneath TCP's receive window, HTTP/2's flow control and AMQP's prefetch, and the reason those protocols do not require the sender to guess.
The receiver advertises credit representing buffer space it actually has. The sender may transmit up to that credit and then must stop. As the receiver processes data, it returns credit. Overload becomes impossible by construction rather than by convention.
Two properties worth understanding architecturally. It is end-to-end at the layer that implements it — TCP's window protects the kernel socket buffer, not your application's queue, so an application that reads eagerly into an unbounded internal queue has defeated it. And credit is a capacity statement, so setting it too high reintroduces unbounded queueing while setting it too low underutilises the link, which is why HTTP/2's default window is a common tuning target for high-bandwidth transfers.
The transferable idea: expressing capacity as an explicit grant is more robust than expecting senders to infer it from latency or errors.