IoT Architecture Explained: Device, Gateway, Cloud and Application Layers

Most beginner IoT projects start with a sensor wired to an ESP32 and a value printed on the Serial Monitor. The difficult part comes next: where should that value go, who stores it, how does a phone see it, and how does a command travel back to switch a relay? Answering these questions is what IoT architecture is about.

This article breaks a typical IoT system into four layers, explains the job of each one, and shows how the rest of this tutorial series fits into that picture. At the end you will write a small ESP32 sketch that produces a well-structured JSON message, the format that every later tutorial (MQTT, HTTP, ThingSpeak, Firebase, Node-RED) builds on.

The Four Layers

  [Sensors / Actuators]
          |
  DEVICE LAYER     ESP32, Arduino, STM32 + firmware
          |   Wi-Fi, BLE, LoRa, Zigbee, RS-485
  GATEWAY LAYER    Wi-Fi router, Raspberry Pi, LoRa gateway
          |   Internet (TCP/IP, TLS)
  CLOUD LAYER      MQTT broker, REST API, database, rules
          |   HTTPS, WebSocket, push notifications
  APPLICATION      Dashboard, mobile app, alerts, analytics

1. Device layer

This is the hardware that touches the physical world: a DHT22 measuring temperature, a soil moisture probe, a relay driving a pump. A microcontroller such as the ESP32 reads the sensors, does light processing (averaging, unit conversion, threshold checks) and packages the result into a message. Devices are constrained: limited RAM, limited flash, and often battery power, so the firmware must be small and efficient.

2. Gateway layer

The gateway connects local devices to the internet. For a Wi-Fi ESP32 the gateway is simply your home router, which forwards TCP/IP traffic. For radios that do not speak IP, such as LoRa, BLE or Zigbee, the gateway is an active device, often a Raspberry Pi, that receives radio packets and re-publishes them over the internet. Gateways can also buffer data during internet outages and run local rules so a light still turns on when the cloud is unreachable.

3. Cloud layer

The cloud receives, stores and routes data. Typical pieces are a message broker (Mosquitto, HiveMQ, AWS IoT Core), an HTTP API, a time-series database, and a rules engine that raises an alert when a value crosses a limit. The cloud can be a public service like ThingSpeak or Firebase, or your own server or Raspberry Pi running Mosquitto and Node-RED.

4. Application layer

This is what people actually see: a web dashboard with gauges and charts, a mobile app with switches, SMS or email alerts, and reports. The application never talks directly to the ESP32. It reads from and writes to the cloud layer, which keeps devices hidden behind one controlled entry point.

Two Directions of Data Flow

Every IoT system has two flows. Telemetry moves upward: device to cloud to application, for example a temperature reading every 30 seconds. Commands move downward: application to cloud to device, for example the user tapping a switch to turn on a fan. Telemetry is frequent and tolerant of an occasional lost sample. Commands are rare but must arrive, and the device should report its new state back so the app shows the truth rather than what the user hoped would happen.

Layer	Example hardware or software	Main responsibility	Covered in
Device	ESP32 DevKit + DHT22 + relay	Sense, actuate, format messages	MQTT publisher, HTTP POST, deep sleep tutorials
Gateway	Wi-Fi router, Raspberry Pi with LoRa module	Bridge local network to internet	LoRa point-to-point tutorial
Cloud	Mosquitto, ThingSpeak, Firebase	Receive, store, route, secure	Mosquitto, ThingSpeak, Firebase tutorials
Application	Node-RED dashboard, Blynk app	Display, control, alert	Node-RED and Blynk tutorials

Designing the Device Message

Whatever transport you choose later, the message itself should follow a few rules. Include a device ID so the cloud knows who sent it. Include units in the field names or documentation so nobody guesses whether 30 means Celsius or Fahrenheit. Include a sequence counter so lost messages can be detected. Keep it small: short field names save bytes on every transmission.

The sketch below reads a DHT22 on GPIO 4 and prints one JSON line every 10 seconds. It uses the Adafruit DHT sensor library and ArduinoJson version 7, both installable from the Arduino IDE Library Manager. Install the ESP32 boards package by Espressif from the Boards Manager first.

ESP32 device layer: read DHT22 and build a JSON telemetry message

#include <WiFi.h>
#include <DHT.h>
#include <ArduinoJson.h>

#define DHTPIN  4        // DHT22 data pin (use a 10k pull-up to 3.3 V)
#define DHTTYPE DHT22

DHT dht(DHTPIN, DHTTYPE);
uint32_t seq = 0;        // message counter, lets the cloud spot gaps
String deviceId;

void setup() {
  Serial.begin(115200);
  dht.begin();
  // Use the Wi-Fi MAC address as a unique device ID
  WiFi.mode(WIFI_STA);
  deviceId = "esp32-" + WiFi.macAddress();
  deviceId.replace(":", "");
}

void loop() {
  float t = dht.readTemperature();   // Celsius
  float h = dht.readHumidity();      // percent RH

  JsonDocument doc;                  // ArduinoJson v7 document
  doc["id"]  = deviceId;
  doc["seq"] = seq++;
  doc["up"]  = millis() / 1000;     // uptime in seconds

  if (isnan(t) || isnan(h)) {
    doc["err"] = "dht_read";        // report the fault instead of fake data
  } else {
    doc["temp_c"] = round(t * 10) / 10.0;
    doc["hum_pct"] = round(h * 10) / 10.0;
  }

  serializeJson(doc, Serial);        // one compact line of JSON
  Serial.println();
  delay(10000);
}

{"id":"esp32-246F28A1B2C4","seq":0,"up":2,"temp_c":28.4,"hum_pct":61.2}
{"id":"esp32-246F28A1B2C4","seq":1,"up":12,"temp_c":28.5,"hum_pct":61}

Notice that a failed sensor read produces an err field rather than a zero. A dashboard that silently plots 0 °C during a sensor fault is worse than one with a visible gap. The MAC-based ID is unique per chip, so you can flash the same firmware onto ten boards without editing anything.

Decisions to Make Before Writing Code

Power: mains-powered nodes can stay connected all the time; battery nodes must sleep and wake, which favours short connections and simple protocols.
Range: Wi-Fi covers a house, LoRa can cover a farm, BLE covers a room. Range decides whether you need a separate gateway.
Latency: a relay switched from a phone should respond in well under a second, so the device needs a persistent connection (MQTT or WebSocket) rather than polling.
Data volume: a reading every minute is trivial; audio or images need a very different design.
Ownership: public platforms are quick to start with but have rate limits and terms; a self-hosted Mosquitto and Node-RED setup gives full control but you maintain it.
Security: every layer needs authentication and, over the internet, encryption. Plan it from day one rather than adding it later.

Common Mistakes

Letting the mobile app connect straight to the device's IP address. It works on home Wi-Fi and fails everywhere else.
Sending readings as bare numbers with no device ID, so two sensors overwrite each other in the database.
Putting all logic in the cloud. If the internet drops, a local threshold such as switching off a heater should still work on the device.
Hard-coding Wi-Fi passwords and server addresses, which makes every change a re-flash. Later tutorials cover WiFiManager provisioning and OTA updates.

Summary

An IoT system is a chain of four layers: devices that sense and act, gateways that bridge to the internet, a cloud that stores and routes, and applications that people use. Telemetry flows up and commands flow down, and both should carry a device ID and clear units. With a clean JSON message ready on the ESP32, the next step is choosing how to send it, which is the subject of the protocol comparison tutorial.