IoT Architecture

What it is

IoT architecture describes the systems, protocols, and patterns used to connect physical devices — sensors, actuators, embedded computers, industrial equipment — to cloud-based or edge processing infrastructure. An IoT system collects data from the physical world (temperature, pressure, vibration, location, imagery), processes and stores it, derives insights or triggers actions, and may send commands back to devices to control their behaviour.

Modern IoT architectures are typically organised into three tiers: the device layer (constrained hardware running embedded firmware), the gateway/edge layer (more capable compute close to devices that aggregates, filters, and pre-processes data), and the cloud layer (scalable storage, analytics, and management services). These tiers interact via lightweight messaging protocols designed for constrained, potentially unreliable networks.

Why it exists

Physical devices cannot send raw sensor data directly to cloud databases at high frequency — constrained hardware, limited power budgets, intermittent network connectivity, and sheer data volume make this impractical. IoT architecture provides a structured approach to aggregating device data through progressively more capable tiers, each adding normalisation, filtering, routing, and storage appropriate to the tier's capabilities. The architecture also solves the fleet management challenge: controlling, updating, and monitoring thousands or millions of devices requires a structured device management layer rather than ad-hoc SSH access.

When to use

• Any system requiring collection of data from physical sensors or devices at scale.
• Industrial automation: monitoring machinery health, predictive maintenance, process control.
• Smart buildings: HVAC control, energy monitoring, access control, occupancy sensing.
• Connected products: home appliances, wearables, vehicle telematics.
• Agriculture, utilities, logistics — any physical-world monitoring application.

Typical architecture

THREE-TIER IOT REFERENCE ARCHITECTURE
───────────────────────────────────────
  [Device Layer]
    Sensors / actuators (temperature, pressure, camera, motor)
    Microcontroller (ESP32, STM32, nRF52) or SBC (Raspberry Pi)
    Firmware: embedded C/C++, MicroPython, RTOS (FreeRTOS, Zephyr)
    Connectivity: WiFi, BLE, Zigbee, LoRaWAN, NB-IoT, LTE-M

  [Gateway / Edge Layer]
    Protocol translation: BLE/Zigbee/Z-Wave → MQTT over TLS
    Local buffering: SQLite or flat files during cloud connectivity loss
    Edge compute: lightweight filtering, aggregation, anomaly detection
    Hardware: industrial PC, Raspberry Pi, AWS Snowcone

  [Cloud Layer]
    IoT broker (MQTT): AWS IoT Core, Azure IoT Hub, HiveMQ
    Message routing: topic rules → Kinesis / Event Hubs / Pub/Sub
    Stream processing: Lambda/Functions, Kinesis Data Analytics, Flink
    Time-series storage: InfluxDB, Timestream, TimescaleDB, Azure ADX
    Cold storage: S3 / Azure Data Lake (Parquet for analytics)
    Device management: OTA, provisioning, shadow/twin, registry

MESSAGING PROTOCOLS
────────────────────
  MQTT (Message Queuing Telemetry Transport)
  - Publish/subscribe; designed for constrained devices
  - TCP-based; persistent sessions survive disconnects
  - QoS 0: at-most-once (fire and forget)
  - QoS 1: at-least-once (acknowledged; duplicates possible)
  - QoS 2: exactly-once (4-way handshake; highest overhead)
  - Last Will and Testament (LWT): broker publishes message if device disconnects uncleanly
  - Retained messages: broker stores last message per topic; new subscribers receive immediately
  - Port 8883 for MQTT over TLS

  CoAP (Constrained Application Protocol)
  - UDP-based; designed for constrained networks (lossy, low bandwidth)
  - RESTful (GET/POST/PUT/DELETE) over UDP
  - Observe extension for server-push (analogous to MQTT subscribe)
  - Used in LTE-M/NB-IoT deployments where TCP is too heavyweight

  AMQP (Advanced Message Queuing Protocol)
  - TCP-based; richer routing semantics (exchanges, queues, bindings)
  - Used for gateway-to-cloud or cloud-to-cloud messaging
  - Azure Service Bus and Azure IoT Hub support AMQP

DEVICE SHADOW / DIGITAL TWIN
──────────────────────────────
  Problem: device may be offline; cloud app needs to know device state
           and set desired configuration without polling

  Device Shadow (AWS) / Device Twin (Azure):
  - JSON document in the cloud representing device state
  - "reported" section: device writes its current state
  - "desired" section: cloud app writes desired configuration
  - Delta: broker notifies device of difference on reconnect
  - Device applies delta, updates "reported" → shadow converges

  Digital Twin (advanced):
  - Full virtual model of physical asset (Azure Digital Twins, AWS IoT TwinMaker)
  - Includes relationships between assets (building → floor → room → thermostat)
  - Enables graph queries: "which thermostats in building A are above 25°C?"

TELEMETRY INGESTION PIPELINE (AWS)
────────────────────────────────────
  Device → MQTT → AWS IoT Core
           IoT Core Rule → Kinesis Data Streams
           Kinesis → Lambda (enrichment/validation)
           Lambda → Timestream (recent, queryable)
                  → S3 Parquet (long-term, analytics)
           S3 → Athena / Glue (ad-hoc queries, ML features)

Pros and cons

Implementation notes

Topic design: MQTT topic hierarchy should be designed deliberately as it drives filtering, access control, and rule routing. A common pattern: {tenantId}/{deviceType}/{deviceId}/{eventType} — for example, acme/thermostat/therm-42/telemetry and acme/thermostat/therm-42/commands. This hierarchy allows per-device ACLs (a device can only publish to its own topic), fleet-level subscriptions (acme/thermostat/+/telemetry subscribes to all thermostats), and routing rules that target specific event types.

Last Will and Testament: Configure an LWT message for every device connection pointing to a known "device offline" topic. When the broker detects an unclean disconnect (keepalive timeout), it publishes the LWT automatically. Cloud-side rule actions can update the device's shadow reported state to {"status":"offline"} and trigger an alert if the device does not reconnect within a threshold period.

Common failure modes

• Message storms on reconnect: When thousands of devices reconnect simultaneously after a cloud outage, the burst of QoS 1 re-transmissions and session resumptions can overwhelm the broker; use jitter in device reconnect backoff (e.g., randomise reconnect delay 0–60s).
• Flat topic namespaces: Using simple topics like telemetry without device or tenant hierarchy makes per-device access control impossible and prevents efficient routing rules.
• Shadow divergence: If devices go offline for extended periods, shadow "desired" vs "reported" divergence can accumulate. Design firmware to handle batch delta application on reconnect and validate that the desired state is still applicable (e.g., desired firmware version 2.0 when device is already on 3.0).

Decision checklist

• Is MQTT topic hierarchy designed for per-device ACLs and fleet-level subscriptions?
• Are Last Will and Testament messages configured for all device connections?
• Is device shadow/twin used for desired vs reported state synchronisation?
• Does the ingestion pipeline handle backpressure and buffering for message burst scenarios?
• Is telemetry routed to both a time-series store (hot path) and object storage (cold path)?
• Are devices using mutual TLS (mTLS) with unique per-device X.509 certificates?

Example use cases

• Industrial predictive maintenance: Vibration and temperature sensors on motors publish MQTT telemetry every second; gateway aggregates to 10-second summaries; cloud rule routes to Kinesis; stream processing detects anomalies using rolling window statistics; alert triggers work order in CMMS.
• Smart building HVAC: Thermostats publish temperature every minute; cloud app writes desired temperature setpoints to device shadows; thermostats poll shadows on reconnect and apply setpoints; floor-level aggregate reports update a digital twin.

Related patterns

• Edge Computing — Moving processing from cloud to gateway/edge tier for latency, bandwidth, and offline-operation benefits.
• Device Management — OTA firmware updates, provisioning, and fleet management for IoT device fleets.
• IoT Security — Per-device X.509 certificates, mTLS, secure boot, and certificate rotation at scale.
• IoT Data Pipeline — Deep dive into ingestion, time-series storage, and stream processing for IoT telemetry.

Further reading

• What is AWS IoT Core? — AWS Documentation
• IoT Architecture — Microsoft Learn
• MQTT Specification — mqtt.org