IoT Architecture Patterns: Hub-and-Spoke, Mesh, and Edge-Cloud Hybrid
Every IoT deployment starts with the same core question: how do data and commands flow between devices and the cloud? The answer shapes everything — device selection, network topology, failure modes, and operational cost. There are three dominant patterns, each with distinct strengths.
Pattern 1: Hub-and-Spoke
The simplest and most common pattern. A central gateway (hub) communicates with the cloud. All field devices (spokes) communicate only with the gateway.
┌─────────────┐
│ AWS IoT / │
│ Cloud │
└──────┬──────┘
│ MQTT TLS
┌──────┴──────┐
│ Gateway │
│ (Pi / EC2) │
└──┬──┬──┬────┘
│ │ │
BLE │ │ │ Zigbee / RS485
┌───┘ │ └───┐
[Dev-1] [Dev-2] [Dev-3]
How it works: Field sensors use low-power local protocols (BLE, Zigbee, Modbus RS-485). The gateway acts as a protocol translator, converting local protocol frames to MQTT messages for the cloud. Only the gateway has internet connectivity — devices themselves are radio-silent to the outside world.
When to use hub-and-spoke:
Real example — Smart Building HVAC: A 10-floor office building deploys 200 Zigbee temperature/CO₂ sensors and 50 BLE occupancy sensors. Each floor has one Raspberry Pi gateway. Gateways aggregate 250 readings into batch MQTT publishes every 30 seconds. Cloud cost: ~$15/month. Sensor battery life: 18+ months.
Failure modes:
Configuration example:
{
"gateway": {
"id": "gw-building-a",
"protocols": ["zigbee", "ble", "modbus"],
"upstreamBroker": "mqtts://your-endpoint.iot.us-east-1.amazonaws.com:8883",
"bufferPath": "/var/lib/gateway/buffer.db",
"batchIntervalMs": 30000,
"maxBatchSize": 500
},
"zones": [
{ "id": "floor-1", "devices": 25, "protocol": "zigbee" },
{ "id": "floor-2", "devices": 18, "protocol": "zigbee" },
{ "id": "lobby", "devices": 12, "protocol": "ble" }
]
}
For a complete gateway implementation, see [Building a Production IoT Gateway with Raspberry Pi and Node.js](/blog/raspberry-pi-iot-gateway-nodejs).
Pattern 2: Mesh Networking
Devices form a self-healing network where each node can relay messages for its neighbors. No single gateway is required — data hops across nodes until it reaches an edge node with cloud connectivity.
[Dev-A]──[Dev-B]──[Dev-C]──[Border Router]──→ Cloud
│ │ │
[Dev-D]──[Dev-E] [Dev-F]
│
[Dev-G]
Technologies: Thread (IPv6 mesh, used in Matter devices), Zigbee mesh, LoRa mesh, Bluetooth Mesh, OpenThread.
When to use mesh:
Real example — Precision Agriculture: A 500-hectare vineyard deploys LoRa mesh nodes across rows. Each node carries soil moisture, temperature, and leaf wetness sensors. Nodes relay data peer-to-peer until reaching three solar-powered border routers at the field perimeter. Two of those three can go offline without losing coverage.
Trade-offs:
ASCII mesh diagram for a warehouse:
[Aisle-A1]──[Aisle-A2]──[Aisle-A3]
│ │ │
[Aisle-B1]──[Aisle-B2]──[Aisle-B3]──[Router-1]──→ Cloud
│ │ │
[Aisle-C1]──[Aisle-C2]──[Aisle-C3]
│
[Router-2]──→ Cloud (redundant)
Pattern 3: Edge-Cloud Hybrid
The most sophisticated pattern. Intelligence and processing are distributed: some analysis happens on field gateways (edge), some in the cloud. Data flows bidirectionally.
Sensors → [Edge Gateway]
├─ Local ML inference (anomaly detection)
├─ Local alerting (no cloud latency)
├─ Local data aggregation + compression
└─ Cloud sync (aggregates + alerts + raw on-demand)
↓
[Cloud Platform]
├─ Fleet management
├─ Historical analytics
├─ Model retraining → push new model to edge
└─ Dashboard + API
When to use edge-cloud hybrid:
Real example — Industrial CNC Machine Monitoring: CNC machines generate vibration data at 10kHz per axis. Streaming raw data to the cloud would require 2.4 GB/day per machine and hundreds of dollars per month in data transfer. Instead:
Hybrid data strategy:
{
"edgeRules": [
{
"sensor": "vibration",
"localAction": "fft_anomaly_detection",
"sendToCloud": "anomaly_events_only",
"localRetention": "1h raw, 30d hourly summary"
},
{
"sensor": "temperature",
"localAction": "threshold_alert",
"sendToCloud": "all_readings_1min_aggregate",
"localRetention": "7d raw"
}
]
}
Choosing the Right Pattern
| Factor | Hub-and-Spoke | Mesh | Edge-Cloud Hybrid | |--------|--------------|------|-------------------| | Complexity | Low | High | High | | Reliability | Medium | Very High | Very High | | Latency | Low | Medium | Lowest possible | | Cost | Low | Medium | Medium-High | | Scale | Medium | High | High | | Best domain | Buildings, agriculture | Large outdoor, warehouse | Industrial, healthcare |
Decision flow:
Real Production Mix: Smart Factory
In practice, most large deployments combine all three:
Production Floor (Mesh, Thread)
↓
Floor Gateways (Hub-and-Spoke aggregation)
↓
Edge Server in plant (local inference + alerting)
↓
Cloud (dashboards, fleet management, analytics)
The mesh handles the harsh RF environment on the factory floor. Gateways aggregate across zones. The edge server handles time-critical alerting and local ML. The cloud handles everything that doesn't need to be fast.
For the cloud layer of this architecture, see [IoT Fleet Management with AWS IoT Core](/blog/iot-fleet-management-aws-iot-core). For the edge processing decision framework, see [Edge Computing in IoT: On-Device vs Cloud](/blog/edge-computing-iot-on-device-vs-cloud).
Need help designing the right IoT architecture for your use case? [Contact Code Caracal](/contact) — we've shipped these systems for clients across 15+ countries.