IoT Device Platform

01Ten million devices are ‘connected’ — how do we know when one drops?

Every device holds one long-lived MQTT connection (MQTT — the lightweight publish/subscribe protocol built for constrained devices) with a keepalive heartbeat; a missed keepalive window marks the device gone, and its LWT (Last Will and Testament — a message the broker publishes on the device’s behalf when it drops ungracefully) fires presence events on crashes only — a clean disconnect says goodbye itself.

02Where does the sensor data go?

Telemetry flows one way at fleet scale: devices publish readings to per-device topics, the broker fans them into an ingest stream, and no downstream consumer — however slow — is ever allowed to backpressure the connection plane.

03A command is sent to a device that is offline — then what?

A command to an offline device is not an error — it is the product: the command persists as desired state in the device shadow with a version and timestamp, queues as a QoS 1 message (QoS — MQTT’s per-message delivery contract) in the device’s persistent session, and completes when the device reconnects, drains the queue, reconciles the shadow delta, and reports back.

04The same command arrives twice — does the door unlock twice?

Delivery is at-least-once, effect is exactly-once: QoS 1 redelivers on any doubt, so every command carries a command id and the device applies it idempotently — the door told to unlock twice unlocks once.

05The device reconnects after three days — does the old unlock fire?

Every command carries an expiry: an unlock issued three days ago must never fire on today’s reconnect — expired commands transition to a terminal expired state the caller can observe, and the shadow delta, not queue order, decides what still applies.

06What stops an impostor from connecting as someone else’s device?

Every device authenticates with its own X.509 certificate (X.509 — the standard format for public-key identity certificates) over mutual TLS; identity comes from the certificate the platform issued, never from a device-claimed id, and one leaked credential revokes one device — not the fleet.

01What does 10M concurrent actually require?

Ten million concurrent connections, horizontally: the broker layer shards by connection — published benchmarks demonstrate 10M concurrent MQTT connections on a clustered deployment of commodity nodes — so growing the fleet means adding broker nodes, never finding a bigger box.

02A command was issued an hour ago — who can prove what happened to it?

No command silently vanishes: every command reaches a terminal state — acknowledged, expired, or failed — that the issuing caller can observe; the contract is at-least-once delivery plus device-side idempotency, because exactly-once transport (QoS 2) is not offered by major cloud brokers.

03A region loses power for an hour, then gets it back — what happens in second one?

Survives its own comeback: a regional outage ending brings hundreds of thousands of devices back at once, so clients back off with jitter and the server admits reconnects at a controlled rate — the recovery is throttled, not trusted.

04How stale may state be — and how stale may an action be?

Bounded staleness for state, zero tolerance for stale actions: shadow reads may lag reported state by seconds, but an actuation past its expiry must never execute — freshness is enforced twice, by the server-side sweep and by the device’s check at apply time.

05One device’s credentials leak — what is the blast radius?

Per-device identity, revocable in minutes: mutual TLS with per-device certificates, a revocation path that cuts a compromised device off at its next connect, topic-level authorization scoping each device to its own topics, and no API that trusts a device-claimed identity.