MQTT broker

MQTT is a lightweight, publish/subscribe messaging protocol widely used in IoT and distributed systems. It is designed to work efficiently in environments with limited resources, low bandwidth, high latency, or unreliable network connections.

At the heart of every MQTT architecture lies the MQTT broker — the central server that manages all communication between clients. The broker receives messages from publishers, determines which subscribers are interested in them, and reliably delivers them according to the protocol’s rules.

An MQTT client is any device, application, or service that connects to the broker to send or receive messages. Clients range from small IoT sensors to complex enterprise applications. Common examples:

• IoT devices — publish sensor data such as temperature, humidity, or GPS location.
• Mobile or web applications — subscribe to updates from connected devices.
• Back-end services — collect, process, or visualize incoming data streams.

Each client can take on one or more roles:

• Publisher — sends messages to a specific topic.
• Subscriber — receives messages from one or more topics.
• Hybrid — acts as both, depending on the use case.

By routing all communication through the broker, clients remain loosely coupled, making systems more flexible, scalable, and maintainable.

An MQTT topic is a structured string used by the broker to route messages between publishers and subscribers. Topics define the channel of communication and are the backbone of the publish/subscribe model.

Key characteristics:

• Hierarchical structure — topics are organized in levels separated by slashes (/). Example: home/livingroom/temperature.
• Message flow — publishers send to a specific topic; subscribers register interest and receive all messages published to matching topics.

MQTT supports wildcards to simplify subscription patterns:

• + (single-level wildcard) — matches exactly one level. Example: home/+/temperature matches home/livingroom/temperature and home/kitchen/temperature.
• # (multi-level wildcard) — matches all remaining levels. Example: home/# matches everything under home/.

This flexible topic system allows clients to filter messages with precision, making MQTT efficient for large-scale, event-driven communication.

See Topics and wildcards for the full guide.

The broker is the central component that enables communication in an MQTT system. Clients never communicate directly — all messages flow through the broker. Key responsibilities:

• Managing client connections — establishing, monitoring, and maintaining sessions.
• Authentication and authorization — validating identities and enforcing access control policies.
• Message routing — receiving published messages and distributing them to all matching subscribers.
• Session and state management — tracking subscriptions and storing undelivered messages for offline clients.
• Quality of Service — guaranteeing delivery according to the selected QoS level (at most once, at least once, or exactly once).

A client initiates a connection by sending a CONNECT packet containing:

• Client identifier (clientId)
• Protocol version (MQTT 3.1.1 or MQTT 5.0)
• Optional username and password
• Clean session flag or session expiry interval
• Optional Last Will and Testament (LWT) message

The broker validates the connection request by checking credentials — username/password, SSL/TLS certificates, or token-based mechanisms. Once authenticated, the broker enforces authorization policies, determining which topics the client is allowed to publish to and subscribe from. On success, it replies with CONNACK confirming session parameters. On failure, the connection is refused.

The client sends a SUBSCRIBE packet with one or more topic filters and the desired QoS level. The broker replies with SUBACK confirming the granted QoS levels.

A client sends a PUBLISH packet containing the topic name, message payload, QoS level, and optional retain flag. Depending on QoS, acknowledgment packets (PUBACK, PUBREC, PUBREL, PUBCOMP) are exchanged to guarantee delivery.

The broker matches the published message topic against all active subscriptions and forwards the message to each matching subscriber, respecting the per-subscriber QoS, delivering retained messages where applicable, and queuing messages for offline subscribers with persistent sessions.

Subscribers receive the message in a PUBLISH packet from the broker. Based on QoS, they may send acknowledgment packets. Once processed, subscribers can act on the message — logging, storing, visualizing, or triggering downstream actions.

A client sends a DISCONNECT packet to close the connection cleanly. On unexpected disconnects, the broker triggers the LWT message (if configured) and preserves session state based on persistence settings.

TBMQ supports the full range of MQTT 3.1, MQTT 3.1.1, and MQTT 5.0 protocol features.

• Quality of Service — at most once (0), at least once (1), exactly once (2).
• Keep alive — periodic heartbeat to detect broken connections quickly. See Keep alive.
• Last Will and Testament — predefined message published automatically on unexpected disconnect. See Last will and testament.
• Retained messages — stores the last message on a topic so new subscribers receive the most recent state instantly. See Retained messages.
• Topic-based routing — efficient matching using hierarchical topics and wildcards.
• Session persistence — stores subscriptions and undelivered messages for clients that reconnect.
• Shared subscriptions — distributes messages among a group of subscribers for load balancing. See Shared subscriptions.

• Scalability — handles thousands to millions of concurrent connections.
• Performance — optimized for low latency and high throughput.
• Durability — critical messages and session data are stored persistently to survive restarts.
• Security — TLS/SSL encryption, authentication, and fine-grained access control.
• High availability and clustering — supports clustering, load balancing, and fault tolerance.
• Integration — connects with external systems such as Kafka, databases, and cloud services.

TBMQ provides all of these capabilities: horizontal scalability to millions of clients, high throughput with low latency, persistence powered by Redis and Kafka, built-in TLS/SSL, clustering with fault tolerance, and integration with Kafka, other brokers, and HTTP-based services.

1. Open-source brokers — free, customizable, and community-maintained. Suitable for prototyping, self-hosted deployments, and integration into larger systems.
2. Commercial brokers — enterprise-grade features including clustering, dashboards, advanced security, and SLA-backed support. Ideal for organizations that need guaranteed reliability, high availability, and professional support.
3. Cloud-based brokers (MQTT-as-a-Service) — fully managed services where the provider handles deployment, scaling, maintenance, and uptime. Ideal for rapid adoption and use cases where infrastructure management should be outsourced.
4. Embedded brokers — extremely lightweight brokers running directly on edge devices, gateways, or inside applications for local processing, offline-first scenarios, and edge computing environments where low latency is critical.

Criterion	What to look for
Scalability	Handles your projected connections and message throughput with room to grow
High availability	Clustering, replication, and load balancing for production uptime
Performance	Low latency and high throughput under real-world load
Security	TLS/SSL, authentication, authorization, and fine-grained access control
Persistence	Durable message storage — retained messages, offline queues, external database integration
Integration	Compatibility with Kafka, SQL/NoSQL databases, monitoring tools, and cloud platforms
Community and support	Active community or enterprise support for troubleshooting and long-term maintenance
Cost	Open-source (free, DIY) vs. commercial (license + support) vs. cloud (subscription-based)

TBMQ meets all of these criteria — enterprise-level scalability, clustering, persistence, strong security, and deep integration options, while remaining cost-efficient to operate and maintain. This makes it a strong choice for both open-source adopters and enterprises looking for a production-ready MQTT platform.

The MQTT broker is the backbone of any MQTT-based system, enabling efficient and reliable communication between distributed devices and services. It plays a critical role in diverse domains — IoT ecosystems, smart homes, industrial automation, connected vehicles, and large-scale data infrastructures.

By offloading responsibilities like message routing, delivery guarantees, and connection management to the broker, client devices remain lightweight and resource-efficient. This reduces device complexity and improves scalability, security, and overall system reliability — making the MQTT broker a cornerstone of modern connected applications.