DEV Community

John Cheng
John Cheng

Posted on

Introduction to a General IoT Platform Architecture

#iot #architecture #systemdesign #cloud

1. Overview

A typical Internet of Things (IoT) system consists of several major components, including end devices, IoT communication infrastructure, business services, data storage, and user-facing applications.

The primary goal of an IoT platform is to:

Allow users to interact with and manage connected devices through applications such as mobile apps and web applications, while enabling devices to send data, status updates, and events to the cloud and receive commands from cloud services.

A commonly used high-level architecture looks like this:

┌─────────────────────────────────────────────────────────────┐
│                     Application Layer                       │
│                                                             │
│             Mobile App / Web / Mini Program / API           │
└──────────────────────────┬──────────────────────────────────┘
                           │
                     HTTP / WebSocket
                           │
                           ▼
┌─────────────────────────────────────────────────────────────┐
│                      Business Services                      │
│                                                             │
│       API Service / Business Service / User Service         │
│                                                             │
│  User Mgmt │ Device Mgmt │ Authorization │ Command Mgmt      │
└───────────────┬──────────────────────┬──────────────────────┘
                │                      │
                ▼                      ▼
        ┌───────────────┐      ┌────────────────┐
        │ Cache / Redis │      │ Database       │
        │               │      │                │
        │ Real-time     │      │ Business data  │
        │ state / cache │      │ / history      │
        └───────────────┘      └────────────────┘
                                       ▲
                                       │
                              ┌────────┴────────┐
                              │                 │
                              │                 │
┌─────────────────────────────┴─────────────────┴─────────────┐
│                    IoT Communication Layer                  │
│                                                             │
│                       MQTT Broker                            │
│                                                             │
│   Message Routing │ Connection Mgmt │ Topic │ QoS │ Session │
└─────────────────────────────┬───────────────────────────────┘
                              │
                            MQTT
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                         Device Layer                        │
│                                                             │
│       MCU / Gateway / Sensor / Controller / IoT Device      │
│                                                             │
└─────────────────────────────────────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

This is not the only possible architecture, but it represents a common and practical design pattern for IoT systems.

2. Major Components of an IoT System

A typical IoT platform can be divided into several logical layers:

Application Layer
        ↓
Business Service Layer
        ↓
IoT Communication Layer
        ↓
Device Layer

Supporting the entire system:

Data Storage
Caching
Message Queues
Logging & Monitoring
Security
Enter fullscreen mode Exit fullscreen mode

Different products may implement these components differently, but the layered architecture provides a useful and reusable design model.

3. Device Layer

The Device Layer connects the digital system to the physical world.

Devices may include:

  • Microcontroller-based devices
  • Sensors
  • Controllers
  • Gateways
  • Industrial equipment
  • Smart home devices
  • Vehicles
  • Embedded systems
  • Other connected devices

Devices are typically responsible for:

  1. Collecting data
  2. Executing commands
  3. Storing essential local configuration
  4. Establishing communication with the cloud
  5. Reporting status and events
  6. Providing basic offline functionality when network connectivity is unavailable

A device normally does not need to maintain a direct business connection with a mobile application. Instead, it communicates with the cloud through the IoT communication layer.

A typical communication path is:

Device
   │
   │ MQTT
   ▼
MQTT Broker
Enter fullscreen mode Exit fullscreen mode

MQTT is widely used in IoT because of its lightweight communication model, publish/subscribe mechanism, and suitability for devices operating over constrained or unreliable networks.

4. IoT Communication Layer

The IoT Communication Layer is responsible for:

Providing reliable and efficient message exchange between devices and cloud services.

An MQTT Broker is a common component of this layer.

For example:

Device A ──┐
Device B ──┤
Device C ──┼──→ MQTT Broker
Device D ──┤
Device E ──┘
Enter fullscreen mode Exit fullscreen mode

A device can publish messages:

Device
   │
   │ publish
   ▼
MQTT Broker
Enter fullscreen mode Exit fullscreen mode

Cloud services can also publish commands to devices:

MQTT Broker
   │
   │ publish
   ▼
Device
Enter fullscreen mode Exit fullscreen mode

The MQTT Broker primarily handles message transport and routing rather than complex business logic.

Typical broker responsibilities include:

MQTT Broker
    │
    ├── Message routing
    ├── Client connection management
    ├── Topic management
    ├── QoS handling
    └── Session management
Enter fullscreen mode Exit fullscreen mode

Business logic such as:

User authorization
Device management
Business rules
Data processing
Command management
Enter fullscreen mode Exit fullscreen mode

should normally be handled by the Business Service Layer.

5. Business Service Layer

The Business Service Layer is the core of the IoT platform.

It connects:

User Applications
        ↕
Business Services
        ↕
IoT Platform
Enter fullscreen mode Exit fullscreen mode

Typical responsibilities include:

  • User management
  • Device management
  • User-device relationships
  • Authorization and access control
  • Command management
  • Business rules
  • Device state management
  • Data processing
  • APIs
  • WebSocket connections
  • Message processing

For example, when a user performs an operation in a mobile app:

APP
 │
 │ WebSocket / HTTP
 ▼
Service
 │
 │ MQTT
 ▼
MQTT Broker
 │
 ▼
Device
Enter fullscreen mode Exit fullscreen mode

The Service validates the user's identity, permissions, and applicable business rules before sending the corresponding command to the device.

After the device executes the command, it can return the result through MQTT:

Device
   │
   │ MQTT
   ▼
MQTT Broker
   │
   ▼
Service
   │
   ├──→ Database
   │
   └──→ WebSocket
          │
          ▼
         APP
Enter fullscreen mode Exit fullscreen mode

This creates a complete end-to-end communication cycle.

6. Communication Between Applications and Services

Mobile and web applications typically do not communicate directly with MQTT Brokers.

A common architecture is:

APP
 │
 ├── HTTP / HTTPS
 │
 └── WebSocket
       │
       ▼
    Service
Enter fullscreen mode Exit fullscreen mode

HTTP/HTTPS is commonly used for operations such as:

  • Login
  • Querying data
  • Updating configuration
  • Retrieving historical data
  • Managing user information

WebSocket is particularly useful for:

  • Real-time status updates
  • Real-time events
  • Command execution results
  • Server-initiated notifications

Both mechanisms can coexist.

For example:

HTTP
 ↓
Query device list
Query historical data
Update configuration

WebSocket
 ↓
Real-time device status
Real-time events
Command results
Enter fullscreen mode Exit fullscreen mode

7. Data Storage Layer

IoT systems can generate large amounts of data. Therefore, different types of data should be handled according to their characteristics and purpose.

Not every piece of data needs to be written directly to a database.

A common approach is:

                    Data
                     │
          ┌──────────┼──────────┐
          │          │          │
          ▼          ▼          ▼
        Cache     Database   Message Queue
          │          │          │
      Real-time   Persistent   Asynchronous
        state        data       processing
Enter fullscreen mode Exit fullscreen mode

7.1 Cache

A caching system such as Redis can be used for:

Device online status
Latest device state
Sessions
Temporary data
Frequently accessed data
Enter fullscreen mode Exit fullscreen mode

The key characteristic is:

A cache is optimized for fast access and should generally not be the only source of persistent data.

7.2 Database

A database is used for data that needs to be stored reliably over time, such as:

Users
Devices
Device configuration
Permissions
Historical records
Operation records
Event records
Command records
Enter fullscreen mode Exit fullscreen mode

The primary role of the database is:

Reliable persistence and queryable storage of business data.

7.3 Message Queue

As the system grows, a message queue can be introduced:

MQTT
  │
  ▼
Service
  │
  ▼
Message Queue
  │
  ├──→ Data Processing
  ├──→ Statistics
  ├──→ Notifications
  ├──→ Logging
  └──→ Other Services
Enter fullscreen mode Exit fullscreen mode

This prevents every MQTT message from having to be processed synchronously inside the message-receiving path.

8. Real-Time Communication vs. Persistent Storage

This is an important principle in IoT architecture.

Suppose a device reports:

temperature = 25.3
Enter fullscreen mode Exit fullscreen mode

The system may need to handle this data in two different ways.

For the current device state:

Real-time state
      ↓
    Redis
      ↓
Current temperature = 25.3°C
Enter fullscreen mode Exit fullscreen mode

For historical analysis:

Historical data
      ↓
   Database
      ↓
Timestamp
Device
Temperature
Enter fullscreen mode Exit fullscreen mode

Therefore:

Real-time communication and persistent data storage are separate concerns.

The database should not simply be used as a relay for every real-time message.

A more appropriate design is:

                 ┌──→ Redis
                 │
MQTT → Service ──┼──→ Database
                 │
                 └──→ Message Queue
Enter fullscreen mode Exit fullscreen mode

Different data paths can then be selected according to their purpose.

9. Commands, Events, and State

It is useful to distinguish three fundamental types of IoT data from the beginning of the system design.

Command

A Command represents:

An instruction requesting a device or service to perform an operation.

Examples:

SetConfig
Reboot
Start
Stop
UpdateFirmware
Enter fullscreen mode Exit fullscreen mode

Typical direction:

APP
 ↓
Service
 ↓
MQTT
 ↓
Device
Enter fullscreen mode Exit fullscreen mode

Event

An Event represents:

Something that happened in the system or on a device.

Examples:

DeviceStarted
SensorTriggered
ConfigurationChanged
ErrorOccurred
Enter fullscreen mode Exit fullscreen mode

Typical direction:

Device
 ↓
MQTT
 ↓
Service
 ↓
APP / Database / Other Service
Enter fullscreen mode Exit fullscreen mode

State

State represents:

The current condition or status of a device or system component.

Examples:

online
offline
running
stopped
temperature
battery
firmware_version
Enter fullscreen mode Exit fullscreen mode

Current state is often stored in a cache for fast access and may also be persisted in a database when required by the business.

10. Example of an End-to-End Data Flow

Consider a user performing an operation on a device through a mobile application.

Step 1: The user initiates an operation 

APP
 │
 │ WebSocket
 ▼
Service
Enter fullscreen mode Exit fullscreen mode

Step 2: The Service processes the request 

Service
 │
 ├── Authenticate user
 ├── Check authorization
 ├── Check device state
 └── Create Command
Enter fullscreen mode Exit fullscreen mode

Step 3: The command is sent to the device 

Service
 │
 │ MQTT
 ▼
MQTT Broker
 │
 ▼
Device
Enter fullscreen mode Exit fullscreen mode

Step 4: The device executes the command 

Device
 │
 ├── Execute command
 └── Generate Event
Enter fullscreen mode Exit fullscreen mode

Step 5: The device reports the result 

Device
 │
 │ MQTT
 ▼
MQTT Broker
 │
 ▼
Service
Enter fullscreen mode Exit fullscreen mode

Step 6: The Service processes the result 

Service
 │
 ├──→ Database
 │
 ├──→ Redis
 │
 └──→ WebSocket
          │
          ▼
         APP
Enter fullscreen mode Exit fullscreen mode

The user can then see the operation result in the application.

11. Why Is This Architecture So Common?

One of the major advantages of this architecture is decoupling.

For example:

APP
 ↓
Service
 ↓
MQTT
 ↓
Device
Enter fullscreen mode Exit fullscreen mode

Each layer has a clearly defined responsibility.

The application does not need to understand the device's low-level communication details.

The device does not need to understand the application's user interface or business logic.

The MQTT Broker does not need to understand complex business rules.

The Service Layer connects these components and implements the business logic between them.

This makes it possible to evolve individual components independently:

Application can change
        ↓
Service remains largely unchanged

Device implementation can change
        ↓
Service remains largely unchanged

MQTT infrastructure can change
        ↓
Business logic remains largely unchanged
Enter fullscreen mode Exit fullscreen mode

This loose coupling makes the system easier to maintain and extend.

12. Architecture as the System Scales

As the number of devices and users increases, the Business Service Layer can be further divided into specialized services:

                         APP / Web
                             │
                       API Gateway
                             │
              ┌──────────────┼──────────────┐
              │              │              │
              ▼              ▼              ▼
         User Service   Device Service   Data Service
              │              │              │
              └──────────────┼──────────────┘
                             │
                       Message Queue
                             │
                             ▼
                       MQTT Service
                             │
                             ▼
                       MQTT Broker
                             │
                             ▼
                          Devices
Enter fullscreen mode Exit fullscreen mode

Supporting infrastructure may include:

                 ┌── Redis
                 │
Services ────────┼── Database
                 │
                 └── Object Storage
Enter fullscreen mode Exit fullscreen mode

This allows individual components to scale independently according to their workloads.

For example:

Device Service
    × 3

MQTT Consumers
    × 10

Data Service
    × 4
Enter fullscreen mode Exit fullscreen mode

There is no need to scale the entire system as a single unit.

13. Security

Security should be treated as a fundamental part of the IoT architecture.

At a minimum, the system should consider:

Users
 │
 ├── Authentication
 ├── Authorization
 └── Session / Token

Devices
 │
 ├── Device ID
 ├── Device Credentials
 ├── TLS
 └── MQTT ACL

Communication
 │
 ├── HTTPS
 ├── WSS
 └── MQTT over TLS
Enter fullscreen mode Exit fullscreen mode

Other important security considerations include:

  • Device identity and authentication
  • User authentication
  • Authorization
  • Data encryption
  • Firmware integrity
  • Key management
  • Audit logging
  • Protection against device impersonation
  • Protection against replay attacks

Security should not be added only after the system is completed. It should be considered from the beginning of the architecture design.

14. Logging, Monitoring, and Operations

Observability is another important part of an IoT platform.

A production system should ideally provide:

                 Monitoring
                     │
       ┌─────────────┼─────────────┐
       │             │             │
     Metrics        Logs         Traces
       │             │             │
       ▼             ▼             ▼
   CPU / Memory    Service       Request
   MQTT sessions   Logs          Tracing
   Device count    Errors        Message flow
Enter fullscreen mode Exit fullscreen mode

This makes it possible to determine whether a problem is caused by:

Device
   ↓
Network
   ↓
MQTT Broker
   ↓
Service
   ↓
Database
   ↓
Application
Enter fullscreen mode Exit fullscreen mode

rather than simply observing that “the application is not responding.”

15. A More Complete General IoT Architecture

Combining the concepts above, a general-purpose IoT platform can be represented as follows:

┌──────────────────────────────────────────────────────────────┐
│                       Application Layer                      │
│                                                              │
│              Mobile App / Web / API / Other Clients         │
└─────────────────────────────┬────────────────────────────────┘
                              │
                       HTTPS / WebSocket
                              │
                              ▼
┌──────────────────────────────────────────────────────────────┐
│                        API Gateway                            │
└─────────────────────────────┬────────────────────────────────┘
                              │
                              ▼
┌──────────────────────────────────────────────────────────────┐
│                     Business Services                        │
│                                                              │
│  User │ Device │ Command │ Data │ Notification │ Other       │
└─────────────┬──────────────────────────────┬─────────────────┘
              │                              │
              ▼                              ▼
        ┌───────────┐                  ┌──────────────┐
        │   Redis   │                  │   Database   │
        │   Cache   │                  │              │
        └───────────┘                  └──────────────┘
              ▲                              ▲
              │                              │
              └──────────────┬───────────────┘
                             │
                       Message Queue
                             │
                             ▼
┌──────────────────────────────────────────────────────────────┐
│                     IoT Platform Layer                       │
│                                                              │
│                       MQTT Broker                            │
│                                                              │
│    Connection │ Routing │ QoS │ Session │ Authentication      │
└─────────────────────────────┬────────────────────────────────┘
                              │
                             MQTT
                              │
                              ▼
┌──────────────────────────────────────────────────────────────┐
│                        Device Layer                          │
│                                                              │
│   Sensor │ MCU │ Gateway │ Controller │ Embedded Device      │
└──────────────────────────────────────────────────────────────┘


              ┌───────────────────────────────┐
              │     Security & Observability │
              │                               │
              │ Logs │ Metrics │ Tracing      │
              │ IAM │ TLS │ Audit │ Key Mgmt  │
              └───────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

16. General Architecture Principles

When planning an IoT platform, the following principles provide a useful starting point.

Principle 1: Use Clear Layers

Define clear responsibilities for:

Application
Service
MQTT
Device
Database
Enter fullscreen mode Exit fullscreen mode

Each layer should focus on its own responsibilities.

Principle 2: Keep Components Decoupled

The application should not depend directly on device implementation details, and devices should not depend on application-specific business logic.

Principle 3: Separate Real-Time Communication from Persistence

Do not treat the database as a general-purpose relay for all real-time messages.

Principle 4: Distinguish Commands, Events, and State

Clearly separating:

Command
Event
State
Enter fullscreen mode Exit fullscreen mode

makes the system easier to understand and extend.

Principle 5: Prefer Stateless Services

Whenever possible, avoid storing critical state inside an individual Service instance.

Instead:

Service × N
    │
    ├── Redis
    ├── Database
    └── Message Queue
Enter fullscreen mode Exit fullscreen mode

This makes horizontal scaling much easier.

Principle 6: Design for Intermittent Connectivity

IoT devices cannot assume that network connectivity will always be available.

Depending on the product requirements, devices should support appropriate mechanisms such as:

Local state
Local configuration
Offline operation
Automatic reconnection
Message retry
Enter fullscreen mode Exit fullscreen mode

17. Summary

A general IoT platform can be understood as:

                Users
                  │
                  ▼
             APP / Web
                  │
                  ▼
               Service
                  │
        ┌─────────┴─────────┐
        │                   │
        ▼                   ▼
      Data                MQTT
        │                   │
        │                   ▼
        │                 Device
        │
        ▼
   Database / Cache
Enter fullscreen mode Exit fullscreen mode

As the system grows, additional components can be introduced:

API Gateway
Message Queue
Microservices
Object Storage
Monitoring
Logging
Tracing
Security
Enter fullscreen mode Exit fullscreen mode

The architecture does not need to be overly complicated at the beginning. A practical evolution path is often:

Phase 1
APP
 ↓
Service
 ↓
MQTT
 ↓
Device
 ↓
Database


Phase 2
Add Redis
Add WebSocket
Add Message Queue


Phase 3
Split Services
Scale MQTT Consumers
Optimize Database
Add Monitoring


Phase 4
Kubernetes
Microservices
Multi-Region Deployment
High Availability
Elastic Scaling
Enter fullscreen mode Exit fullscreen mode

The fundamental goal is not to follow one rigid architecture, but to establish clear boundaries between applications, business logic, communication infrastructure, devices, and data.

A well-designed IoT platform should allow these components to evolve independently while remaining reliable, secure, observable, and scalable as the number of devices and the complexity of the business increase.

Top comments (0)