Queues decouple producer from consumer

From The Language of the System, by Rich Hickey:

Now we get to moving things around. I think it's one of the things in Clojure maybe I didn't make clear enough because I didn't need to wrap them is that the queues in java.util.concurrent are awesome. If you're not using them as part of your system designs internally, you're missing out. And, in the large, queues also rule because they have this really great characteristic. They're completely decoupling.

Messages: What happens with the message? A says something to B. When A says something to B, what does A need to know? B. That's a problem. If A puts something on a queue, who gets it? Don't know. So that decoupling is really good, both in the identity of the consumer, also in the availability.

If I put something in a queue and the person who is supposed to consume it is not running, do I care? Not usually. There may be backflow and some other kind of considerations, but the availability of the consumer is also something that you don't care about, right? Again, a directly connected message: A said something to B. If B is not around, that's now a problem for A. If A puts something on a queue, presumably if you can make the queue more available than B, you get this independence, both in the identity of the consumer and the availability of the consumer, which is extremely strong.

The other great thing about conveyor belts and queues is that what do they do? What's their job? Move stuff. What's their other job? There is no other job. That's all they do, right? So it has that characteristic we had from before.

I mean, when you get to pub/sub, you end up with routing and moving, and they're both on this slide, but that's really strong. Queues are extremely important. Queues are decidedly different from messages for those reasons. Messages, they need an available consumer, and you need to know who you're talking to. It's architecturally completely different.

Related: Functions and assembly lines.