ZeroMQ

Pros and Cons of Publish-Subscribe

ØMQ’s low-level patterns have their different characters. Pub-sub addresses an old messaging problem, which is multicast or group messaging. It has that unique mix of meticulous simplicity and brutal indifference that characterizes ØMQ. It’s worth understanding the trade-offs that pub-sub makes, how these benefit us, and how we can work around them if needed.

First, PUB sends each message to “all of many,” whereas PUSH and DEALER rotate messages to “one of many.” You cannot simply replace PUSH with PUB or vice versa and hope that things will work. This bears repeating, because people seem to quite often suggest doing this.

More profoundly, pub-sub is aimed at scalability. This means large volumes of data, sent rapidly to many recipients. If you need millions of messages per second sent to thousands of points, you’ll appreciate pub-sub a lot more than if you need a few messages a second sent to a handful of recipients.

To get scalability, pub-sub uses the same trick as push-pull, which is to get rid of back-chatter. This means that recipients don’t talk back to senders. There are some exceptions—e.g., SUB sockets will send subscriptions to PUB sockets—but this is anonymous and infrequent.

Killing back-chatter is essential to real scalability. With pub-sub, it’s how the pattern can map cleanly to the Pragmatic General Multicast (PGM) protocol, which is handled by the network switch. In other words, subscribers don’t connect to the publisher at all; they ...