IoT Architecture Patterns: From Edge Computing to Cloud Analytics

IoT System Layers

An IoT system has four layers: devices (sensors, actuators, embedded systems), gateways (aggregation points that protocol-translate and pre-process), cloud platform (message broker, ingestion pipeline, storage, analytics), and applications (dashboards, alerts, ML models, business integrations). Each layer has different constraints — devices are resource-constrained, gateways handle protocol diversity, the cloud handles scale, and applications handle business logic.

The design principle: push computation to the edge when latency, bandwidth, or reliability requires it; push it to the cloud when scale, ML capability, or centralized management requires it. The balance between edge and cloud is the fundamental architectural decision in every IoT system.

Edge Device Layer

Edge devices range from simple sensors (temperature, vibration, pressure) to complex embedded systems (Raspberry Pi-class computers running Linux). The constraint is consistent: limited compute, limited memory, unreliable connectivity, and power constraints (many devices are battery-powered). Firmware must be efficient, fault-tolerant, and updatable over-the-air (OTA).

We use ESP32 for simple sensor nodes (low cost, WiFi/BLE, adequate compute for basic processing), Raspberry Pi or BeagleBone for gateway devices (full Linux, sufficient compute for edge ML), and custom PCBs with STM32 microcontrollers for production deployments where cost and power matter at scale. Every device runs a minimal RTOS or embedded Linux with a secure boot chain and encrypted firmware updates.

Gateway and Aggregation Layer

Gateways aggregate data from multiple devices, translate protocols (BLE/Zigbee/Modbus to MQTT/HTTP), perform edge processing (filtering, aggregation, anomaly detection), and buffer data during connectivity outages. A factory floor might have 200 sensors communicating via Modbus RTU, aggregated by 10 gateways that publish to MQTT. The gateway reduces cloud bandwidth by 90% — only aggregated data and anomalies are sent to the cloud; raw sensor data stays local.

Edge processing on the gateway includes: data filtering (remove duplicate or out-of-range readings), aggregation (compute averages, min/max over time windows), and edge ML (run a trained model locally for real-time anomaly detection). Edge ML models are typically TensorFlow Lite or ONNX Runtime models quantized for the gateway's hardware.

Message Broker and Protocol

MQTT is the standard IoT messaging protocol. It's lightweight (2 bytes of overhead per message), supports publish/subscribe with quality-of-service levels (QoS 0: at most once, QoS 1: at least once, QoS 2: exactly once), and handles unreliable networks gracefully. MQTT brokers (EMQX, Mosquitto, HiveMQ) handle millions of concurrent device connections.

For cloud IoT platforms, AWS IoT Core, Azure IoT Hub, and Google Cloud IoT Core provide managed MQTT brokers with built-in device authentication, rules engines (route messages to other AWS/Azure/GCP services), and device shadow (a cloud-side representation of the device's desired and reported state). We use AWS IoT Core for most projects — its rules engine and integration with the AWS ecosystem (Lambda, Timestream, Kinesis) reduces custom infrastructure.

Cloud Ingestion Pipeline

The cloud ingestion pipeline receives millions of messages per day and routes them to appropriate services. The architecture: IoT Core rules route messages by topic to different destinations — telemetry data to Amazon Timestream (time-series database), alerts to Lambda functions, state changes to DynamoDB, and raw data to S3 for archival and batch analytics. For high-throughput scenarios (100K+ messages/second), route through Kinesis Data Streams first, then fan out to multiple consumers.

Data modeling for time-series is critical. Each device's telemetry should be stored with device ID, timestamp, and measurements as columns. Timestream automatically handles time-based partitioning, retention policies (move old data to cheaper storage), and efficient time-range queries. Avoid storing IoT data in relational databases — the write volume and query patterns (time-range scans) are a poor fit.

Analytics and ML at Scale

IoT analytics has two modes: real-time (dashboards, alerts, anomaly detection) and batch (trend analysis, predictive maintenance, model training). Real-time analytics uses stream processing (Kinesis Data Analytics, Apache Flink) to compute metrics over sliding time windows. Batch analytics uses Athena or Spark to query the S3 data lake.

Predictive maintenance is the highest-value IoT ML application. Train models on historical sensor data to predict equipment failures before they occur. The pipeline: collect labeled failure data, engineer features from sensor time-series (vibration frequency analysis, temperature trends), train models (gradient boosting for tabular features, LSTMs for raw time-series), and deploy models to the edge (for real-time prediction) or cloud (for batch scoring). The ROI of predictive maintenance in industrial settings typically pays for the entire IoT platform within 12 months — this is the reference architecture our IoT development team builds from, paired with IoT dashboard and analytics work for the visualization layer.