Requests versus messages
The web mostly works on a request and response basis. A client asks for something, a server answers, and the exchange ends. That suits browsing, but it is awkward for devices. A sensor that has new data would have to wait to be asked, or the server would have to ask over and over. Asking repeatedly wastes battery and bandwidth, and a device behind a home router often cannot be contacted directly at all.
Publish and subscribe, often shortened to pub/sub, reverses the arrangement. Devices send messages when they have something to say, and anything interested receives them. Neither side needs to know the other’s address.
The three parts
Publishers send messages. A temperature sensor publishes a reading.
Subscribers register interest and receive matching messages. A dashboard, a logging service or a heating controller might subscribe to temperature readings.
The broker sits in between. It accepts all published messages and delivers each to the subscribers who asked for it. Because the broker does the matching, publishers and subscribers are decoupled: a new subscriber can be added without changing the sensor, and the sensor can be replaced without changing the subscribers.
Topics
Messages are labeled with a topic, a short text path such as home/livingroom/temperature. Subscribers choose which topics they want. Most systems allow wildcards, so one subscription can cover every room’s temperature, or everything in the house. A sensible topic naming scheme, planned early, saves much confusion later, because renaming topics across many devices is tedious.
A message is just a payload attached to a topic. It might be a number, a short text or a structured record. The pattern does not define what the payload means, so publishers and subscribers must agree on the format. That is part of the larger difficulty of device interoperability.
A concrete example
Imagine a small home setup. A door sensor publishes “open” to a door topic. A hallway light controller subscribes to that topic and switches on. A phone app subscribes too and shows a notification. The sensor never learns who is listening, and adding a siren later needs no change to the sensor at all.
Delivery levels
Networks drop messages, so pub/sub protocols for devices commonly offer choices about delivery guarantees. A widely used one has three levels:
- At most once. Sent once with no acknowledgment. Fast and light, but a message can be lost.
- At least once. Resent until acknowledged. Nothing is lost, but duplicates are possible.
- Exactly once. A longer handshake prevents both loss and duplicates, at the cost of more traffic.
Higher guarantees use more energy and bandwidth. A temperature reading sent every minute can tolerate an occasional loss. A command to unlock a door deserves more care, and the receiver should be built to handle a repeated command safely.
Features that suit devices
- Retained messages. The broker can keep the most recent message on a topic and give it to any new subscriber immediately. This is useful for status values, so a new dashboard shows the current state without waiting for the next reading.
- Last will. A device can register a message for the broker to publish if the device disappears unexpectedly. That allows others to learn that it went offline, which helps with offline operation and monitoring.
- Persistent sessions. A subscriber that disconnects can receive messages it missed when it returns, depending on settings.
- Small overhead. Protocols in this family are designed with tiny headers and a long-lived connection, which suits constrained microcontrollers and unreliable links.
Where the broker lives
A broker can run on a local gateway, on a home hub, on a server in a data center, or as a managed cloud service. A local broker keeps working when the internet is down and keeps data inside the building. A cloud broker is reachable from anywhere and can serve many sites. Some systems bridge the two: local devices use the nearby broker, which forwards selected topics to the cloud. This is an example of the local processing choice.
Trade-offs
- The broker is central. If it fails, messages stop. For important systems, brokers can be clustered or duplicated.
- Always-on connections. Holding a connection open costs power on some radios. Very low-power devices that sleep for long periods may connect only to send, then disconnect.
- No built-in meaning. The broker moves bytes. Nothing checks that a payload is sensible.
- Ordering and timing. Messages from different publishers may arrive in a different order than they were sent, so timestamps in the payload are often useful.
- Scale and cost. A large fleet produces many messages. Topic design and message frequency affect broker load.
Security considerations
A broker with no access control is an open invitation. Good practice includes requiring authentication for every client, giving each device its own credentials rather than a shared one, restricting which topics each client can publish or subscribe to, and encrypting the connection. A device allowed to publish anywhere could, if compromised, send false readings or commands to others. Exposing a broker to the internet with default settings is a frequent and avoidable mistake.
When to choose it
Pub/sub is a good fit when many devices produce data for several consumers, when devices sit behind firewalls, or when systems will change over time. A plain request-response interface can be simpler when a device is queried occasionally and is directly reachable. Many real systems use both: messaging for telemetry and events, and request-response for configuration.