Understanding the MQTT Publish-Subscribe Model

At the heart of the MQTT protocol is the publish-subscribe (pub-sub) communication pattern. Unlike the traditional client-server model where clients communicate directly with a server, pub-sub decouples the message sender (the publisher) from the message receiver (the subscriber). This is achieved through a central component called a broker.

This architectural choice is what makes MQTT so powerful and scalable for IoT applications.

The Three Key Roles

There are three main roles in any MQTT system:

Publisher: A client that sends (publishes) messages. A good example is an ESP32 sensor device reporting data.
Subscriber: A client that receives (subscribes to) messages, such as a dashboard application.
Broker: The central server that receives all messages from publishers and routes them to the appropriate subscribers. Many people start by setting up a broker on a Raspberry Pi for their local network.

Crucially, a single MQTT client can act as a publisher, a subscriber, or both simultaneously.

Topics: The Address of Your Data

Publishers don't send messages directly to subscribers. Instead, they publish messages to a topic. A topic is simply a string that acts as an address or a label for a message, structured hierarchically like a file path.

For example, this is a common topic structure in a smart home setup: home/livingroom/temperature

The Publish-Subscribe Flow

The process is simple and elegant:

sequenceDiagram participant P as Publisher (Sensor) participant B as Broker participant S1 as Subscriber 1 (Dashboard) participant S2 as Subscriber 2 (Database) S1->>B: SUBSCRIBE to "home/livingroom/temperature" S2->>B: SUBSCRIBE to "home/livingroom/temperature" P->>B: PUBLISH "22.5" to "home/livingroom/temperature" B->>S1: FORWARD "22.5" B->>S2: FORWARD "22.5"

Subscription: Clients connect to the broker and subscribe to topics they care about.
Publication: A publisher connects and sends a message to a specific topic.
Distribution: The broker forwards the message to all subscribed clients.

The Power of Decoupling

This model provides three critical forms of decoupling:

Type of Decoupling	Description	Benefit
Space Decoupling	The publisher and subscriber do not need to know each other's IP address or location.	You can add or remove any number of publishers or subscribers without affecting the others. The system is highly scalable.
Time Decoupling	The publisher and subscriber do not need to be running at the same time.	The broker can store messages for offline subscribers (using QoS and persistent sessions), ensuring no data is lost.
Synchronization Decoupling	Operations on both sides do not need to be halted during publishing or receiving.	This asynchronous nature is highly efficient for resource-constrained devices.