> I like the author's solution (always use bounded queues) because it usually forces you to confront back-pressure up front. I work on a system that can proces

> I like the author's solution (always use bounded queues) because it usually forces you to confront back-pressure up front. I work on a system that can process a million financial transactions a second, and this principle of "always use bounded queues" has definitely made an incredible impact on the design. We use bounded queues everywhere — and everything is also static allocation: memory, network resources, disk too, even all the messages that might possibly be needed to execute different variants of the distributed consensus protocol. It's really nice coding on it, because all the limits are clearly defined. It forces a little more upfront thinking. This thinking can be a little difficult for a day or two, but the net result is a better design. I love Little's law.