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.