2.4 Architecture Takeaways and Extensions
2.4.1 This Chapter's Engineering Checklist: Key Points for Architecture Selection
Before selecting an architecture, think through which link of your data loop is broken. Some teams spend six months on research and then discover that platform capability was never the problem — they simply never drew a clear boundary between "intelligent decision-making" and "rule-based judgment." There is no universal answer in architecture selection — a solution that suits a smart building may fail latency targets once moved onto an industrial production line. Selection is at heart a trade-off: among cost, latency, scalability, and maintenance complexity, find the line that fits both your current scale and your future growth.
The engineering judgments behind the core concepts settle into a six-step checklist; take it and screen your own project against it, item by item.
1. Assess whether you need an intelligence layer
Not every IoT scenario needs a dedicated intelligent inference layer. The judgment takes two steps.
- Can the rules be enumerated exhaustively? Is the business logic fixed (raise an alarm when temperature exceeds 40 °C), or does it need to adjust dynamically to context (deciding whether to start pre-cooling by weighing weather forecasts, electricity prices, and equipment wear)? Only the latter needs the intelligence layer's reasoning and planning.
- Is the execution path programmable? If the decision criteria can be written into a rule engine, there is no need to introduce an LLM. Rule engines are deterministic, auditable, and low-latency — they fit any scenario with clear boundaries.
Decision advice: whatever rules can handle, run on a rule engine; bring in the intelligence layer only where rules fall short. Do not adopt AI for AI's sake. DC3's approach is to make the intelligence layer an independent microservice (the Agentic Center) that calls underlying data and services through tool interfaces and stays compatible with mainstream LLM API standards. Treat it as an optional module — no AI attached in the project's early stage, connected on demand at mid-stage.
2. The microservice split principle: by business domain, not by technology stack
When splitting, ask three questions: How strong is this feature's data coupling? Tightly coupled features belong in the same center. How often does this feature change? Split out the frequently changing services to avoid one change dragging the whole system along. Does this feature need to scale independently? Data modules with high message throughput should be able to scale out on their own.
DC3's split reflects exactly this: Gateway handles the single entry point and routing, Auth handles authentication and tenant isolation, Manager handles device metadata, Data handles unified data and storage, and Agentic handles intelligent inference and execution. Reuse this principle and check your own project against it: if two features change for different reasons and have different scaling needs, they belong in different microservices. Do not split along vague names like "data service" or "common service."
3. Data storage selection: a time-series database plus a message queue is the standard
IoT data is characteristically write-heavy and read-light, and accessed as time series. Once the number of points reaches a certain scale, the IO of a relational database becomes the bottleneck. The storage-layer choice sets the ceiling on the whole architecture's write capacity. The time-series database stores historical point values; the message queue decouples data production from consumption. Make the concrete choice by weighing daily write volume, query patterns, and the team's operations experience. Common pairings include TimescaleDB or InfluxDB alongside RabbitMQ or Kafka, but you should not lock into one product — keep the interfaces abstract.
4. Security and permissions: the baseline that runs through every layer
From device onboarding to user access, security is not any single layer's job. In the design, authorization and tenant isolation live in a unified security center: every request carries its authentication context through the gateway, and once verified, that context can be reused by the other services. This yields an important design principle: centralized authentication, distributed authorization — authentication is completed uniformly at the edge, while each center checks authorization on its own. Key checkpoints:
- Is device authentication independent of user authentication? Keep them separate: devices use pre-provisioned tokens or certificates; users use JWT.
- Is there tenant isolation? Each tenant sees only its own devices and data.
- Is command execution risk-graded? High-risk actions require a second confirmation to prevent misoperation.
- Is communication encrypted? MQTT/TCP connections between devices and the platform should enable TLS.
5. Scalability: planning for future growth
Designing the architecture for three times the current scale costs far less than refactoring after the fact. Scalability shows up at three levels.
- Pluggable protocol drivers: onboarding new devices should not mean touching core code. DC3's approach is to run each protocol driver as a separate service that plugs into the data pipeline through a standard interface. Even if the project starts with a single protocol, leave the driver abstraction layer in place.
- Horizontally scalable storage: both the time-series database and the message queue should support clustered deployment.
- Replaceable intelligence-layer models: do not hard-code the LLM into your code. DC3's intelligence layer is compatible with mainstream LLM APIs, so replacing a model requires no business-code changes.
6. Open-source comparison: DC3 vs Kaa vs ThingsBoard
When choosing an open-source IoT platform, coverage of the four-layer architecture, microservice maturity, and built-in support for an intelligence layer are the core competitive strengths. The table below summarizes the architectural characteristics of three representative projects, based on each project's publicly released official documentation (specific capabilities follow each project's latest stable version).
| Dimension | IoT DC3 | ThingsBoard | Kaa |
|---|---|---|---|
| Open-source license | AGPL 3.0 | Apache 2.0 | Apache 2.0 |
| Architecture style | Microservices (one gateway + four centers) | Monolith + optional microservices | Microservices (K8s-native) |
| Intelligence-layer support | Built-in Agentic Center | No independent intelligence layer | No independent intelligence layer |
| Device access | 36 driver modules (as of the mainline in August 2026, including a small number of data-source/virtual drivers), via Gateway | Basic protocols via integration layer | Device SDK, edge gateway |
| Data storage | Time-series DB + message queue | Cassandra/SQL + rule engine | Time-series DB + Kafka |
| Clustering | Horizontal scaling supported | Supported (extra components needed) | Native K8s cluster |
| Best-fit scenarios | AI closed loops, strong control | Device management, visualization | Edge computing, large-scale deployment |
Selection advice: if you need the closed-loop capability of "device data → intelligent inference → autonomous execution," DC3 is, among mainstream open-source projects, the one that explicitly builds the intelligence layer in as an independent microservice. If the emphasis is device management, data visualization, and rule triggering, ThingsBoard offers a richer dashboard ecosystem and a more mature rule engine. If your team already has Kubernetes operations experience and strong edge-computing requirements, Kaa's K8s-native architecture and edge SDK deserve attention.
The technology route always depends on which link is your business bottleneck — a broken control loop, insufficient visualization, or constrained scalability. Run the preceding five-step checklist over it and the answer will emerge on its own. Finally, condense the six steps into a printable review sheet and pin it on the team's whiteboard:
| No. | Check item | Self-check result | Decision notes |
|---|---|---|---|
| 1 | Is an intelligence layer needed? | Rules enumerable? Execution path programmable? | Decide when to introduce AI |
| 2 | Is the microservice split by business domain? | Feature cohesion? Change frequency? Scaling needs? | Avoid splitting by tech domain |
| 3 | Does the data storage selection match? | Write-heavy, read-light? Time-series needed? Message queue? | Settle the DB+MQ pairing |
| 4 | Does security run through every layer? | Centralized authentication? Distributed authorization? Risk grading? TLS? | Security center design |
| 5 | Is scalability reserved? | Pluggable protocol drivers? Horizontal storage scaling? Replaceable models? | Architectural foresight |
| 6 | Have open-source options been compared? | Do they meet intelligence-layer/microservice/storage/clustering needs? | Selection conclusion |
This table is not just a record-keeping tool for selection; it is the entry ticket to every architecture review — go through it before the meeting and save the team hours of discussion. The core of this architecture-selection framework is: clear boundaries, domain-based decomposition, security throughout, optional intelligence. There is no perfect architecture, only the choice that best fits the current business bottleneck.
2.4.2 Further Reading and Next Learning Steps
Between understanding the four-layer architecture and practicing the five-layer architecture lies the hurdle of getting it running with your own hands. The learning material below is organized into three steps, each ending with a self-check standard — treat it as a roadmap, and finish one step before entering the next.
First step: master the classic four-layer foundation
For the sensing layer, entering through Modbus RTU/TCP is the most direct route. It is enough to understand reading and writing 16-bit values in holding registers — the plainest of industrial protocol actions, and the reference origin for every higher-level protocol that follows. Next, contrast it with OPC UA's address-space model — watch how it packs flat messages into a layered semantic tree. Finally, read MQTT's publish/subscribe model and QoS levels, and work out the full chain of field registers → semantic modeling → cloud pipeline.
The network layer focuses on three low-power wide-area networks (LPWANs): LoRaWAN, NB-IoT, and 5G URLLC; also take note of 5G RedCap as defined in Release 17 (see Section 1.2.4). There is no need to memorize channel parameters, but you should be able to judge the selection across dimensions such as coverage radius, power consumption, and data volume.
For the platform layer, put your energy into three things: columnar storage compression in the time-series database, downsampling windows, and retention policies. These three determine whether queries can still return within seconds after millions of point values have been written.
Keep two references at hand: Internet of Things: Technology and Applications, revised edition, by Sun Limin et al. (field-level reference covering protocol detail in the sensing and network layers), and Martin Kleppmann's Designing Data-Intensive Applications (its chapters on data partitioning, replication models, and consistency boundaries correspond exactly to the theoretical basis of the platform-layer pipeline).
Self-check standard: given a workshop with 200 temperature sensors reporting every 5 seconds, explain the complete path from end to end — sensor → protocol conversion → network hop → downsampling → sharded storage.
Second step: understand how the intelligence layer works
Start with OpenAI's Function Calling documentation to understand how a model generates a function name and structured arguments from Tool definitions. Then compare LangChain's Tool abstraction with the Spring AI @Tool used by DC3 to see how frameworks package registration, invocation, and result return. For security, DC3's MCP integration is useful for inspecting Token introspection, connection context, Tool visibility, and authorization revalidation at invocation time. The current source, however, does not prove complete implementation of the OAuth 2.1 authorization-code flow, dynamic client registration, or every MCP authorization requirement. Finally, read a named revision of the MCP specification and distinguish protocol initialization, HTTP authorization, and platform business permissions.
Self-check standard: be able to explain why logic that a rule engine handles well needs no intelligence layer, and which links the security constraints on tool calling must cover.
Third step: engineering practice and microservice governance
In this step you get hands-on with three open-source projects, in order. First deploy IoT DC3 (github.com/pnoker/iot-dc3): run it on a single machine with docker-compose and manually walk the full chain of device registration → driver configuration → point mapping → rule engine → Agentic Center tool calling, living through a complete new data loop. Next, try ThingsBoard's (github.com/thingsboard/thingsboard) visual drag-and-drop rule engine, compare it with DC3's code-driven approach, and sort out which logic drag-and-drop can handle and which must be handed to the LLM. Finally, look at Apache StreamPipes (github.com/apache/streampipes) for stream processing of industrial data pipelines, as a reference implementation for platform-layer data cleansing and preprocessing.
Two books are recommended for microservice governance: Sam Newman's Building Microservices and Chris Richardson's Microservices Patterns. When you reach the section on two-phase commit, think about how consistency between RabbitMQ delivery and the time-series database write is guaranteed after the data platform receives a command — the most typical trade-off point for microservices in the IoT context.
Self-check standard: be able to run the full DC3 chain independently and produce a written analysis of how the system is split among rule engine, data preprocessing, and AI collaboration.
With the three steps done, look back at the architecture overview figure at the start of this chapter: every layer should now be a deployable, tunable artifact. The direction for going deeper is decided by your target project — device access, data analysis, or AI-assisted operations — each corresponding to a different sub-topic along the paths above.
Read this chapter through the four words: the five-layer architecture gives Sense and Reason explicit layers, the data loop gives Act a deterministic path, and the evolution of the architecture itself — from the classic four layers to an intelligence layer — is the first visible form of Evolve at the architecture level.