The short answer

This estimator turns six workload assumptions into a minimum broker test envelope. It keeps concurrent connections, publish throughput, routed deliveries, persistent sessions, reconnect pressure, and offline backlog visible as separate demands. That separation matters: a broker can look healthy during steady publishing and still fail when thousands of clients restore sessions after an outage.

It is not a vendor sizing calculator. Broker implementations differ in routing indexes, session storage, clustering, authentication, persistence, and operational limits. Use the output to design a benchmark that resembles your system, then measure the broker and infrastructure you intend to run.

Parameters to enter

  • Concurrent connections is the peak number of connected clients, not the registered fleet size. Include gateways, backend consumers, and administrative clients where they share the same cluster.
  • Messages per second is the expected inbound publish rate at the chosen operating point.
  • Average subscriptions per client provides a simple routing-work proxy. Use an observed average from representative clients, not the maximum allowed by policy.
  • Persistent sessions is the percentage of connected clients whose session state survives a disconnect.
  • Reconnects per second after outage is the restoration rate the authentication, network, broker, and session stores must absorb together.
  • Offline backlog messages is the queued population waiting for eligible clients. It is a count, not bytes, because message size and storage overhead must be measured separately.

How the estimate is calculated

The tool reports the entered connection and publish targets directly. Persistent sessions are estimated as:

concurrent connections × persistent-session percentage

The routed-delivery figure is a deliberately simple workload proxy:

messages per second × max(1, average subscriptions per client)

That is not MQTT fan-out semantics. One subscription may match no publications, while one publication may match many shared or ordinary subscriptions. The figure gives a reproducible starting point for a test; a production trace or realistic topic distribution should replace it before procurement.

Reconnects and backlog remain independent targets because combining them into a single score would hide the exact recovery behavior you need to test.

Worked example

Suppose a service expects 100,000 concurrent clients, 5,000 publishes per second, and three subscriptions per client. Sixty percent use persistent sessions. The outage plan allows 2,000 reconnects per second, while one million queued messages may need controlled draining.

The estimator returns 100,000 concurrent connections, 5,000 publishes per second, up to 15,000 routed deliveries per second as the routing proxy, 60,000 persistent sessions, 2,000 authentication and session restores per second, and one million queued messages. A useful benchmark would run the steady workload first, remove a broker node, restore clients through the real identity service, and drain backlog without violating live-message latency or the recovery-time objective.

What the result cannot tell you

The estimator does not predict CPU, memory, disk, network, or node count. It does not model payload size, retained messages, MQTT QoS exchanges, shared-subscription balance, wildcard complexity, TLS handshakes, authorization latency, storage replication, or uneven client behavior. It also cannot establish a safe per-node connection limit.

Test at least four conditions separately: steady state, reconnect recovery, backlog drain, and node loss. Capture latency distributions and recovery time rather than relying only on aggregate throughput. Apply the broker vendor’s supported limits after your own measurements, not in place of them.

Privacy and sharing

Calculation happens entirely in this browser. Submitting the form stores the numeric and selection parameters in the current URL so the scenario can be reopened or shared. Those values may reveal fleet scale, so use representative figures if the real numbers are confidential. No parameter or result is uploaded to IoT 01.

Copy produces a Markdown summary. JSON, CSV, and Markdown exports are generated locally as files by the browser.

FAQ

Is the routed-delivery number a broker guarantee?

No. It is a transparent test proxy based on the average subscription input. Topic matching and consumer topology determine actual fan-out.

Should registered devices equal concurrent connections?

Usually not. Use measured or planned peak concurrency, including non-device MQTT clients that use the same broker estate.

How much headroom should I add?

There is no universal percentage. Derive headroom from failure tests, growth forecasts, deployment lead time, and the recovery objective your team has committed to.

Use Designing for mass device reconnects to turn the reconnect target into backoff, admission-control, session-restoration, and recovery tests.