Fleet scaling problems rarely show up in a pilot — a hundred devices will tolerate almost any architecture. They show up later, usually all at once, when a design choice that was invisible at small scale becomes the bottleneck. Anticipating the handful of things that predictably break is far cheaper than re-architecting under pressure once they do.
Device identity and provisioning
How a device gets its identity and credentials matters more than it seems at pilot scale. Manually provisioning a hundred devices is tedious but survivable; manually provisioning a hundred thousand is not. Fleets that scale smoothly build automated, factory-integrated provisioning early — unique per-device credentials issued at manufacture time, not shared or hardcoded secrets — both because it's the only way to provision at volume and because shared credentials become a serious security liability at scale.
Telemetry ingestion has to be designed for burst, not average
Average message rate is the wrong number to design around. Real fleets generate correlated bursts — a firmware rollout causing every device to reconnect and report status near-simultaneously, a network outage ending with thousands of devices reconnecting in the same few minutes, a scheduled check-in interval that isn't jittered and so fires in lockstep across the fleet. An ingestion pipeline sized for average load falls over exactly when it matters most. Message queuing, backpressure handling, and randomized jitter on scheduled check-ins are standard mitigations.
Command and control patterns need to handle partial failure
Sending a command or update to ten devices and confirming all ten succeeded is trivial. Sending it to a hundred thousand devices, some of which are offline, some of which are on flaky connections, and some of which will fail partway through, requires a fundamentally different pattern — asynchronous delivery with retries, per-device status tracking, and dashboards that surface the failure tail instead of just an aggregate success percentage. Treating fleet-wide operations as fire-and-forget is a common early mistake that becomes an operational blind spot at scale.
Database and query patterns that don't degrade
- Time-series data (telemetry, sensor readings) benefits from purpose-built time-series storage rather than a general-purpose relational database once volume grows — write throughput and retention/rollup patterns differ substantially
- Device-state queries ("show me all offline devices," "show me all devices on firmware version X") need indexes designed for the actual operational questions the team will ask, not just the ones apparent during pilot development
- Data retention policy decided deliberately — raw telemetry at scale is expensive to store indefinitely, and most operational value lives in the recent window plus aggregated history
Multi-tenancy and regional considerations
A fleet destined to operate across multiple regions or serve multiple customer organizations needs data isolation and regional routing designed in from the start — retrofitting multi-tenancy onto a single-tenant data model, or adding regional data residency to a platform built assuming one region, is a substantial rework, not a configuration change.
How we approach this
We size fleet architecture against the target scale from day one — provisioning, ingestion, and command patterns designed for the fleet the product is meant to reach, not just the pilot in front of us. See our cloud & device platform work for how this fits into a full fleet-management build.