MQTT broker

TBMQ is the MQTT broker at the center of a TBMQ deployment — the server every client connects to, and the component that routes every message between publishers and subscribers. For the general concept of what an MQTT broker is and does, see the What is an MQTT broker? guide. This page covers TBMQ specifically: what sets its broker apart, how it classifies clients, and where to configure each broker responsibility.

TBMQ is an open-source broker that speaks MQTT 3.1, 3.1.1, and 5.0, built on Kafka so that no acknowledged message is lost and the cluster scales horizontally with no coordinator node. On a single node it sustains 3 million messages per second; in cluster mode it handles 100 million concurrent connections with no data loss.

Unlike brokers that treat all traffic the same way, TBMQ is designed around the three traffic patterns of real IoT systems — fan-in, fan-out, and point-to-point. See Why TBMQ for the reasoning, and the architecture overview for how Kafka, Netty, the actor system, and the in-memory subscription trie fit together.

The one broker concept unique to TBMQ: every connecting client is classified as either a DEVICE or an APPLICATION client, and that choice determines how the broker persists and delivers its messages.

• DEVICE — publishes frequently and subscribes to a few low-traffic topics (sensors, actuators, gateways). Offline messages are buffered in Redis.
• APPLICATION — consumes high-volume streams and must not miss a message (analytics services, rule engines, backend processors). Each one gets a dedicated Kafka topic and consumer thread.

Choosing the right type for each client is one of the most important decisions in a deployment. See MQTT client type for how the type is assigned, and the client types concept for how each is persisted and scaled.

Every broker responsibility has a dedicated page with the TBMQ parameters, defaults, and UI steps. Use this page as the map:

Responsibility	Reference
Protocol versions, listener ports, and limits	MQTT protocol
Client classification and persistence	MQTT client type
Connection liveness detection	Keep alive
Topic routing and wildcards	Topics
Delivery guarantees (QoS 0/1/2)	Quality of Service
Session state and offline queues	Sessions
Last known value on a topic	Retained messages
Notify subscribers on an ungraceful disconnect	Last will
Load-balancing consumers across a group	Shared subscriptions
Authentication and authorization	Security
Bridging external systems (Kafka, HTTP, MQTT)	Integrations

Point any MQTT client at TBMQ’s default TCP listener on port 1883 — see listener ports for the full set (TCP, TLS, WebSocket, and secure WebSocket) and how to enable the encrypted ones.

To run your own instance, start with getting started and the installation options.