networks//network theory//publish-subscribe
Publish-subscribe is a communication pattern in which producers publish messages to a named channel and consumers subscribe to the channels they care about. An intermediary, the broker, receives every publication and distributes it, so producers and consumers never need to know each other.
Publish-subscribe is a communication pattern in which producers publish messages to a named channel and consumers subscribe to the channels they care about. An intermediary, the broker, receives every publication and distributes it, so producers and consumers never need to know each other.
Without it, A knows B: every application opens its own connection to every data source, and adding a consumer means touching the producers. With it, A knows the broker and B knows the broker. Adding a new consumer is a new subscription, nothing else changes. That decoupling is why the pattern scales to many readers of the same data. REST is request-response with the client naming the resource; pub/sub inverts it, the producer names a topic and whoever cares listens. One asks, the other announces.
An event-driven API fires an event so that processing leaves the request; publish-subscribe generalizes that event to many subscribers, none of them known to the publisher, with the broker keeping them apart.
MQTT is the lightweight protocol that made the pattern standard in IoT; a CAN bus is a hardware-level cousin, where every node sees every frame and picks the identifiers it wants, though CAN is not MQTT.
Decoupling moves the complexity rather than removing it: the broker becomes a component every consumer depends on, delivery guarantees need acknowledgements (MQTT QoS), and a consumer can no longer tell whether silence means nothing changed or the publisher died, which is what retained messages and the last will exist for.
The pattern distributes information; it does not read or write a device. Request-response protocols such as Modbus do that, and the two are layered rather than exchanged (MQTT).