Letting data back up in unbounded queues means (a) you have giant ass queues sitting around hogging resources, (b) upstream components are now going to see serv

Letting data back up in unbounded queues means (a) you have giant ass queues sitting around hogging resources, (b) upstream components are now going to see service times go through the roof as shit sits around doing nothing in these queues, and (c) upstream clients have no way to predict/avoid these service time spikes due to queueing (vs. say, the operations just take a while) and prevents them making intelligent decisions about their own work which could avoid these service time spikes. I've worked in the embedded space now for about a decade (network, storage, databases). Everywhere I've been where the product has no backpressure, the product inevitably suffers from the above issues, which translate directly into customer dissatisfaction. And it's never easy to add backpressure to a system which doesn't have it. It's also not always an option to just "add more capacity" -- there are many situations where that's not possible, or requires time to enact. Meanwhile, your queues are growing without bound. Build backpressure in from the start.