The short answer

A broker owns connection state and message routing; identity lifecycle, business rules, and long-term data belong in adjacent services.

An MQTT broker accepts client connections, authenticates them through configured mechanisms, applies authorization, tracks subscriptions and sessions, and routes publications to matching subscribers. Depending on product and configuration, it may also store retained messages, queued offline messages, and inflight delivery state. It is a messaging component, not the entire IoT platform.

Why a broker exists

Without a broker, every publisher would need to know and reach every consumer. The broker decouples those parties and centralizes topic matching, delivery handshakes, and connection state. Devices can maintain outbound connections while platform services subscribe to the streams they need.

Centralization also creates a critical dependency. A broker must protect tenant boundaries, recover sessions predictably, and keep overload from turning one noisy client into a fleet outage.

How it works

Clients establish MQTT connections and present authentication material. The broker maps each connection to a principal, then evaluates publish and subscribe operations against policy. Topic filters are matched for every publication. Shared subscriptions may distribute matching messages across a consumer group when supported.

Session state can include subscriptions, inflight exchanges, and queued messages. Persistent state improves continuity, but it consumes memory or storage and creates migration work during failover. Offline queues need expiry and size limits. A client that has been absent for months should not receive an unbounded history by default.

Retained messages are stored by topic and sent to new matching subscribers. Will messages are registered at connection time and published after an ungraceful disconnect according to protocol behavior. Maximum packet size, receive maximum, topic aliases, and other MQTT 5 properties influence flow and resource use.

Clusters distribute connections and routing across nodes, but implementations differ. Some replicate session state, some route it to an owning node, and some lose or rebuild parts during failover. Load balancers, DNS, authentication, certificate services, and persistence remain dependencies outside the broker cluster.

What a broker solves

A broker provides standard MQTT connectivity, topic routing, subscriptions, QoS exchanges, retained messages, wills, and session behavior. It can enforce a consistent messaging boundary for devices and services.

Managed brokers can reduce infrastructure operations, while self-hosted products offer deeper control. Neither choice removes the need to understand limits, failure behavior, tenant policy, upgrades, and exit strategy.

What it does not solve

A broker does not provision device identity, define payload semantics, verify physical outcomes, or store analytical history. Plugins can add rules and integrations, but placing business logic inside the broker couples product behavior to the messaging failure domain.

QoS state does not create end-to-end exactly-once business processing. A consumer still needs idempotency. A successful publish acknowledgement does not prove that every downstream service processed the event.

Where it fits—and where it does not

Use a broker for long-lived MQTT clients and asynchronous fan-out. Keep bulk files, complex request APIs, long-running workflows, and analytical storage in systems designed for those jobs. A small deployment may need one carefully operated broker; a large fleet may need regional isolation, admission control, and explicit disaster recovery.

Benchmark with realistic connections, TLS, authentication, topic lengths, subscription fan-out, QoS, session persistence, retained state, payload distribution, and downstream consumers. Test node loss, rolling upgrade, storage pressure, certificate expiry, and a reconnect surge—not only steady-state messages per second.

Define overload behavior before reaching it. Admission limits, per-principal quotas, publish-rate controls, queue expiry, and load shedding should protect established critical traffic without turning rejection into an invisible data gap.

MQTT defines client and broker behavior. TLS protects transport and can authenticate clients. PKI and device identity manage credential lifecycle. ACLs restrict topic operations. Sparkplug B defines industrial MQTT conventions. Queues and streaming platforms may sit downstream for durable processing and replay.

Common misconceptions

“A million connections means million-message throughput” confuses dimensions. “Clustering means no downtime” ignores state and dependencies. “Retained messages are a database” ignores history and query needs. “Broker plugins are free integrations” ignores upgrade and failure coupling. “More nodes fix overload” fails when authentication or downstream storage is the bottleneck.

Select a broker from a production-shaped test and an operating plan. The decisive question is not its best benchmark; it is how the whole system behaves when clients, nodes, and dependencies fail together.