Direct answer

Estimate IoT capacity as a set of independently constrained workloads: concurrent and reconnecting sessions, authentication rate, inbound and outbound messages, bytes, rules, queue depth, storage writes, queries, and backlog recovery. Model normal operation and correlated failure separately. A platform sized only from device count or average messages per second will usually miss the component that fails first.

The useful output is not “supports one million devices.” It is a capacity envelope tied to a workload definition and service objectives—for example, a stated number of connected sessions, a p95 publication distribution, a burst profile, an allowed queue age, and a recovery deadline.

Scope and non-scope

This guide covers sizing a message-oriented IoT platform from device connection through ingestion, processing, and persistence. It applies whether the front door is MQTT, HTTP, or a managed ingestion service.

It does not replace benchmarking on the selected broker, database, network, or cloud service. It also does not provide a universal bytes-per-connection constant: TLS implementation, protocol settings, subscriptions, persistent session state, operating system, and broker design materially change resource use. Vendor quota and regional availability limits must be checked separately.

Define the workload before calculating it

Segment devices by behavior instead of averaging the fleet. For each cohort, record active count, connected fraction, payload-size distribution, publication interval, subscriptions, QoS, retained messages, session expiry, offline queue policy, command frequency, firmware traffic, and expected growth. Preserve p50, p95, and maximum values where distributions are skewed.

For cohort i, a first estimate of inbound publications per second is active devices_i × publications per device per second_i. Bytes per second must include topic names and protocol, TLS, TCP/IP, and link overhead—not only payload bytes. Outbound delivery is a separate calculation: one publication matched by many subscriptions can create substantial fan-out.

Then add scenarios that align device behavior. Power restoration, a cellular-network recovery, certificate rotation, a weather event, or a firmware campaign can synchronize a fleet that is independent during ordinary operation. Model at least these conditions:

Scenario Capacity question
Normal busy hour Can all service objectives hold continuously?
Telemetry burst Can ingest and rules absorb correlated publications?
Reconnect wave Can TLS, authentication, session restore, and subscriptions recover?
Downstream outage How fast does backlog grow and where is it bounded?
Service recovery Can backlog drain without starving live traffic?
OTA campaign Can control and telemetry coexist with binary distribution?

Size each bottleneck explicitly

Connection capacity depends on file descriptors, socket and TLS memory, keep-alive traffic, session records, and subscription indexes. Connection rate depends more heavily on handshakes, authentication, certificate validation, and session restoration. Test them separately: a cluster can hold 500,000 established sessions yet fail to accept a reconnect wave fast enough.

Message capacity includes parsing, authorization, routing, persistence, rule evaluation, serialization, and fan-out. Measure end-to-end latency and CPU per message class, not broker ingress alone. Large payloads and many small payloads with the same byte rate stress different resources.

Queue capacity is time, not merely bytes. Track the age of the oldest useful message and estimate backlog messages ÷ sustainable spare processing rate for recovery. If the live arrival rate is 80,000 messages per second and the pipeline can process 100,000, only 20,000 per second remains for backlog. Recovery may take much longer than the outage.

Storage sizing needs write amplification, indexes, replication, compression, retention, and late-arriving updates. Query traffic must be represented during ingestion tests because operational dashboards and incident investigations often peak when telemetry does.

A defensible capacity process

  1. Define service objectives: connection success, publish-to-durable latency, command latency, allowed loss, maximum queue age, and recovery time.
  2. Build cohort distributions from production traces or representative devices. Remove secrets but preserve timing, topic length, size, and fan-out.
  3. Draw the end-to-end resource path and identify hard quotas, shared dependencies, and single-region limits.
  4. Calculate a first-order envelope for every dimension, then reserve headroom for growth, deployment imbalance, and a failed node or zone.
  5. Create load generators that preserve correlation, session behavior, QoS, authentication, and subscription patterns. Uniform random traffic is not sufficient.
  6. Run steady-state tests long enough to expose memory growth, compaction, retention jobs, and autoscaling delay.
  7. Inject dependency failure and restore it. Measure backlog growth, live-traffic latency, drain rate, and time to return to the objective.
  8. Repeat after meaningful changes to schemas, rules, certificates, client versions, indexes, or infrastructure.

Capacity should be gated by the first violated service objective, not by process survival. A test that drops no messages but increases command latency from seconds to minutes has failed.

Failure modes to expose

Average-based sizing hides correlated peaks and heavy cohorts. Synthetic clients that reconnect cleanly may omit certificate validation, session replay, or resubscription and therefore understate recovery cost. Testing only ingress misses rules, database contention, and subscription fan-out.

Autoscaling may arrive too late because session state cannot move instantly or because the control plane scales after queues have already aged. A nominally redundant cluster may lose more than one node’s capacity when replicas, leaders, or partitions rebalance. Storage can remain within byte limits while index cardinality or write amplification exhausts CPU and I/O.

Finally, retry loops can convert one slow dependency into a platform-wide retry storm. Use exponential backoff, jitter, attempt limits, circuit breaking, and admission control. Reserve capacity for control traffic so a telemetry backlog cannot block revocation, configuration, or recovery commands.

Implementation checklist

  • Devices are segmented into behavioral cohorts with distributions.
  • Connections, connection rate, messages, bytes, fan-out, and storage are separate dimensions.
  • Service objectives include latency, queue age, and recovery time.
  • Reconnect, downstream outage, recovery, and OTA scenarios are load-tested.
  • Tests exercise real authentication, sessions, subscriptions, QoS, and payload shapes.
  • Live traffic retains priority while backlogs drain.
  • Retry budgets, queue limits, and overload admission policies are enforced.
  • Headroom accounts for growth and the intended infrastructure failure tolerance.
  • Dashboards report saturation and service objectives, not only CPU averages.

Primary sources

The OASIS MQTT 5.0 specification is the normative reference for session state, QoS flows, receive maximum, message expiry, and related protocol behavior that shapes broker load. For TLS handshake and session behavior, consult RFC 8446. Combine these standards with the selected broker, database, and cloud provider’s official limit documentation, then validate the complete path under representative load.