Scaling MQTT is not a single broker-size decision. Connection behavior, payload volume, subscriptions, offline queues, authentication, and downstream consumers all create different limits. Enterprise reliability comes from measuring those limits and containing failure—not from assuming every fleet belongs on one endpoint.
Build a workload model from real traffic
Capture at least these inputs for each device class:
- concurrent and peak connected clients;
- connects and disconnects per second;
- messages per second in each direction;
- average and 95th-percentile payload size;
- QoS distribution and retained-message count;
- subscriptions per client and wildcard breadth;
- expected offline duration and queued-message policy;
- daily and event-driven burst patterns.
Calculate both steady-state throughput and a credible burst. A reconnect after a regional network outage often creates more authentication and subscription work than normal publishing.
Replay real client behavior in staging. A test that holds idle sockets open does not represent certificate handshakes, subscription restoration, queued delivery, or downstream processing.
Isolate by failure and ownership boundary
Separate broker runtimes when fleets have different:
- regulatory or data-residency requirements;
- availability targets;
- deployment schedules;
- traffic profiles;
- operational owners;
- customer isolation commitments.
An environment, region, major tenant group, or product line can be a useful boundary. Avoid creating a broker per tiny customer without an operational reason; excessive fragmentation increases policy, monitoring, and upgrade work.
RunMQTT uses isolated broker instances with scoped templates and device identities, so a policy or capacity decision can remain attached to the workload it governs.
Keep topic structure partitionable
A scalable topic tree exposes the dimensions used for ownership and routing:
prod/{region}/{tenant}/{site}/{deviceId}/{channel}
Do not put fast-changing labels into the hierarchy. Use stable IDs, and keep high-cardinality payload fields out of topics. Broad subscriptions such as prod/# become expensive operational and security dependencies; route analytics through intentional consumers and bounded prefixes.
The MQTT topic design guide explains wildcard and permission tradeoffs.
Automate the credential lifecycle
Manual provisioning does not survive enterprise scale. Integrate device manufacturing or enrollment with a workflow that:
- creates the device record;
- assigns a reviewed policy template;
- delivers credentials through a protected channel;
- records activation;
- rotates or revokes credentials;
- decommissions the identity with the hardware.
Use one identity per device whenever possible. If gateways represent downstream equipment, document that trust boundary and limit the gateway to its assigned site or child-device prefix.
Design for reconnect storms
Every client needs exponential backoff with jitter. Roll credentials and firmware in cohorts so an error does not force the whole fleet to reconnect at once.
Capacity tests should include:
- a cold start of the expected cohort;
- a regional outage followed by network recovery;
- expired or rejected credentials;
- restoration of persistent sessions and subscriptions;
- delivery of bounded offline queues;
- slow or unavailable downstream consumers.
Set message expiry and queue limits so recovery work remains useful. Dropping expired telemetry can be safer than allowing a backlog to delay current state.
Separate regional recovery from active distribution
Multi-region design needs a documented business objective. Decide whether the system requires disaster recovery, active-active client distribution, data replication, or all three.
Devices need a deterministic way to discover or select a healthy endpoint. Replicate only the state needed after failover, and define how retained messages, commands, and duplicate events behave across regions. Test recovery with real DNS, certificates, client backoff, and downstream dependencies.
Observe service-level outcomes
Monitor broker health alongside client and consumer behavior:
- successful connection rate and authentication latency;
- connection churn and session restoration;
- publish-to-consumer latency;
- authorization denials;
- queue depth, expiry, and dropped work;
- throughput and payload-size distribution;
- device heartbeat freshness;
- downstream lag and error rate.
Set service-level objectives around product outcomes, such as the percentage of device readings processed within a target time. Broker availability alone can stay green while an analytics consumer is hours behind.
Scale through controlled changes
Treat policy, firmware, certificate, topic schema, and capacity changes as releases. Use canary cohorts, explicit rollback criteria, and an owner watching the relevant telemetry. Review actual usage and cost after each major expansion.
Before choosing the operating model, compare managed and self-hosted MQTT brokers. When isolation, device identity, and predictable fleet operations are the priority, review RunMQTT pricing.