39 IoT Architecture Planner

fundamentals

planner

39.1 In 60 Seconds

This section: In 60 Seconds — Picture a farm owner who needs a dry-soil warning before a pump is damaged.

Plan Backward From the Field Decision

Picture a farm owner who needs a dry-soil warning before a pump is damaged. A diagram with five boxes is not yet an architecture. The owner needs to know where the reading begins, where a safe local action can happen, how the warning travels, and who notices a broken path.

Latency means the time a result takes to travel through the system. A protocol means the agreed rules used to exchange messages. Write the warning deadline, coverage area, energy limit, data owner, and safe action first. Then place sensing, local processing, communication, storage, and the user view around those needs.

Test the plan by losing the wide-area link, delaying a message, restarting one device, and doubling the number of sensors. Check that urgent protection remains local, delayed data keeps its time, recovery has an owner, and the chosen path still fits the stated limits.

This first plan does not select every product or predict exact cost. The deeper sections add volume, energy, range, security, service choice, and field evidence to turn the sketch into a reviewable architecture.

An IoT architecture spans five layers — sensing, networking, processing, cloud, and application. This interactive planner helps you design a complete system by selecting components at each layer, estimating data volumes and costs, and matching your choices to proven architecture patterns.

39.2 Start With the Story

This section: Start With the Story — You will place sensing, processing, connectivity, and cloud services in an architecture that meets your deployment constraints.

You will place sensing, processing, connectivity, and cloud services in an architecture that meets your deployment constraints. Start by listing the data each layer receives and the decisions it must make.

Trace the architecture decision across four beats to see why the five responsibilities must work as one evidence chain.

Packet Pete holds a radio while Bex lays out sensing, networking, processing, cloud, and application responsibilities as one brief. — Architecture evidence is end to end: each responsibility must fit its constraints and preserve the data flow across every handoff.

Test Tessa reveals broken handoffs between the sensor, gateway, processor, cloud service, and application as deployment constraints pull them apart. — Architecture evidence is end to end: each responsibility must fit its constraints and preserve the data flow across every handoff.

39.3 Chapter Scope

This section: Chapter Scope — This chapter focuses on end-to-end architecture decision-making.

This chapter focuses on end-to-end architecture decision-making.

Use Protocol Selector Wizard for protocol-only decisions.
Use Simulation Catalog for broad simulator/tool discovery.
Use this chapter when integrating sensing, connectivity, processing, cloud, and application choices as one design.

Chapter Roadmap

Use the planner in four passes:

First frame the job: application, scale, criticality, and the five responsibility layers.
Then size the sensing and network choices so 500 sensors, 50 hectares, gateway count, and battery life become explicit constraints.
Next move into processing, cloud, application interfaces, cost, and recommendation logic.
Finally use the quizzes, deep dive, and summary to turn the selected architecture into a validation record.

Checkpoints recap the evidence; the existing physics panel and interactives remain companion material.

The mathematical gist. A battery claim needs an energy ledger, not only a charge rating: $E_{cell}=CV$ , $E_{usable}=E_{cell}(1-k)^t(1-\delta)$ , and each operating state spends $E=IVt$ . For the chapter’s illustrative 2.4 Ah, 3.6 V cell, five years at 1% annual self-discharge and 10% derating leaves 7.39 Wh usable; 3 $\mu$ A sleep plus 9,125 short readings spends about 0.546 Wh, while a separate $IR$ check predicts a 0.4 V transmit sag.

39.4 IoT Architecture Planner

This section: IoT Architecture Planner — Treat the planner as a decision record, not just a calculator: each slider should expose one assumption to prove before scale.

Learning Objectives

By using this interactive tool, you will be able to:

Design a complete five-layer IoT architecture from sensing through application delivery
Evaluate edge-versus-cloud processing trade-offs for a given latency and bandwidth budget
Estimate hardware and recurring costs for different architectural approaches
Diagnose potential bottlenecks in data flow, gateway capacity, and processing pipelines
Select an architecture pattern (direct-to-cloud, gateway-based, or edge-heavy) that matches deployment constraints
Justify component choices by linking sensor count, data volume, and cost projections to business requirements

Treat the planner as a decision record, not just a calculator: each slider should expose one assumption to prove before scale.

39.5 How It Works: Turn Requirements Into An Architecture

This section: How It Works: Turn Requirements Into An Architecture — Use the planner as a requirements-to-evidence loop.

Use the planner as a requirements-to-evidence loop.

Name the deployment job. Start with the environment, users, sensing task, latency target, data volume, and maintenance constraints.
Place each layer. Decide what belongs in sensing, connectivity, edge/gateway, cloud, and application layers.
Quantify the stress points. Estimate message rate, payload size, gateway load, storage, recurring cost, and response-time pressure.
Choose the pattern. Select direct-to-cloud, gateway-based, or edge-heavy architecture only after the weak layer is visible.

39.6 Incremental Examples

This section: Incremental Examples — Beginner Example: A single greenhouse sensor can send periodic readings directly to a cloud dashboard if latency is low-risk and connectivity is reliable.

Beginner Example: A single greenhouse sensor can send periodic readings directly to a cloud dashboard if latency is low-risk and connectivity is reliable.

Intermediate Example: A building with many rooms may need a gateway to reduce traffic, normalize protocols, and keep some control local.

Advanced Example: A safety-critical industrial line may need edge processing, buffered data, local failover, and a cloud layer for fleet analytics rather than real-time control.

39.7 Quick Checks

This section: Quick Checks

Physics Phoebe, Physics and measurement-foundations expert

Checkpoint: Architecture Frame

You now know:

The planner is for end-to-end architecture decisions, while the Protocol Selector Wizard is for protocol-only choices.
A complete design must place sensing, networking, processing, cloud, and application responsibilities.
The first evidence loop is simple: name the deployment job, place each layer, quantify stress points, then choose the pattern.

39.8 Try It Yourself

This section: Try It Yourself — Write a five-layer architecture note for one IoT scenario.

Write a five-layer architecture note for one IoT scenario. For each layer, list one chosen component, one assumption, and one validation task.

39.9 See Also

This section: See Also

Protocol Selector Wizard - narrows the connectivity choice inside the architecture.
Sensor-to-Network Pipeline - traces evidence from sensing through transport.
Application Domains Overview - helps anchor the architecture to a real application need.

39.10 Key Concepts

This section: Key Concepts

Architecture layer: One responsibility band in the system, such as sensing, network, processing, cloud, or application.
Placement decision: The choice of whether a function runs on a device, gateway, edge server, or cloud service.
Data-volume estimate: A first-order calculation that turns sensor count, frequency, and payload size into bandwidth and storage pressure.
Gateway capacity: The practical limit on how many devices, messages, protocol conversions, and local tasks one gateway can handle.
Architecture pattern: A repeatable shape such as direct-to-cloud, gateway-centric, edge-heavy, mesh, or high-availability.
Validation task: A specific measurement, pilot, failure drill, or simulation used to prove the architecture’s riskiest assumption.

39.10.1 Key Takeaway

In one sentence: A well-designed IoT architecture balances sensing needs, connectivity options, processing location, and cost constraints across five interconnected layers.

Remember this rule: Process data at the edge when latency matters, send to cloud when you need scale - your architecture should optimize the edge/cloud split for your specific requirements.

No-One-Left-Behind Architecture Loop

Start with a clear deployment scenario and constraints.
Decide one layer at a time, validating dependencies.
Quantify data volume, latency, and cost before finalizing.
Reinforce by testing assumptions with one simulation or lab.

39.11 Prerequisites

This section: Prerequisites

Before using this planner, review:

IoT Reference Models: Understanding of IoT architecture layers
Edge-Fog Computing: Edge vs. cloud processing concepts
Protocol Selector Wizard: Choose connectivity before designing architecture

For Beginners: IoT Architecture = Blueprint for Your System

Simple Analogy: Building a House

Designing IoT architecture is like planning a house:

House Component	IoT Equivalent	Purpose
Sensors (smoke, motion)	IoT Sensors	Detect what’s happening
Wiring	Network/Protocols	Connect everything
Electrical panel	Gateway/Edge	Process locally
Utility connection	Cloud Services	Connect to outside world
Smart home app	Dashboard/App	Control and monitor

Three Architecture Patterns:

Direct-to-Cloud: Sensors → Cloud (simple, but needs internet)
Gateway-Based: Sensors → Gateway → Cloud (most common)
Edge-Heavy: Sensors → Edge Processing → Cloud (smart, less data)

39.12 Step 1: Define Your Application

This section: Step 1: Define Your Application — Next comes scale: do not pick gateways, cloud tiers, or edge processing until deployment size and message rate have numbers attached.

Next comes scale: do not pick gateways, cloud tiers, or edge processing until deployment size and message rate have numbers attached.

Worked Example: Architecture Planning for Smart Agriculture

Scenario: A vineyard owner wants to monitor 50 hectares (500 sensors: soil moisture, temperature, humidity) to optimize irrigation.

Step-by-step planning:

Define scope: 500 sensors across 50 hectares, cellular connectivity (no Wi-Fi), 5-year battery life required
Calculate data volume: 500 sensors × 5 readings/day × 20 bytes/reading = 50 kB/day = 1.5 MB/month
Estimate costs: Sensors ($15 each = $7,500) + gateways ($200 each, need 10 = $2,000) + cellular ($2/month per gateway) = $9,500 upfront + $240/year
Choose architecture: Gateway-based with LoRaWAN (long range, low power) + 4G backhaul, 50% edge processing (local alerts for irrigation triggers)

Illustrative outcome: If this deployment saves 30% of a $40,000 annual water bill, gross savings are $12,000 per year, enough to recover the example’s $9,500 upfront hardware cost within year one before other operating costs.

Putting Numbers to It

Architecture choices should be grounded in data-volume math before selecting gateways, cloud plans, and retention policies:

D_{\text{month}} = \frac{N_{\text{sensors}} \times f_{\text{day}} \times B_{\text{msg}} \times 30}{1024^2} \text{ MB}

where $D_{\text{month}}$ is monthly data volume in MB, $N_{\text{sensors}}$ is sensor count, $f_{\text{day}}$ is messages per sensor per day, and $B_{\text{msg}}$ is bytes per message.

Worked example: With 500 sensors sending every 15 minutes ( $f_{\text{day}}=96$ ) and 32-byte payloads:

D_{\text{month}} = \frac{500 \times 96 \times 32 \times 30}{1024^2} \approx 43.95 \text{ MB/month}

If edge filtering removes 70% of non-actionable records, cloud ingest becomes about $13.2$ MB/month. That reduction directly affects backhaul usage, storage cost, and query latency.

Common Mistake: Underestimating Gateway Count

Problem: Assuming one gateway can cover an entire deployment area.

Reality: LoRaWAN range is heavily affected by terrain and obstacles. A single gateway might reach 2-5 km in open fields, but only 500m in dense agriculture with trees/hills.

Fix: Use radio propagation tools (e.g., RadioMobile) to model actual coverage before ordering hardware. Budget 1 gateway per 20-50 sensors in challenging terrain.

39.13 Step 2: Sensing Layer

This section: Step 2: Sensing Layer

Layer 1: Sensors and Actuators

The perception layer captures physical world data and executes actions.

39.14 Step 3: Network Layer

This section: Step 3: Network Layer

Layer 2: Connectivity

How sensors connect and communicate data.

Decision Framework: Choosing Connectivity Protocol

Use this table to shortlist candidates; confirm coverage, payload, power, and operating cost for your site:

Your Constraint	Choose	Why
Indoor deployment, power available	Wi-Fi	Highest bandwidth, existing infrastructure
Indoor sensors, battery powered	Bluetooth LE or Zigbee	Low-power modes; a typical indoor link may reach 10-30 m, depending on walls and placement
Outdoor, sensors spread 1-5 km	LoRaWAN	Long range and low duty cycle can suit agriculture if a surveyed gateway link covers each sensor
Mobile assets (vehicles, containers)	Cellular (NB-IoT/LTE-M)	Carrier coverage can follow moving assets; check local mobility support and service cost
Urban dense deployment	Thread or Zigbee	Mesh can provide alternate paths around interference if powered routers and suitable channels are available
Multi-year battery target	LoRaWAN or Sigfox	Infrequent transmissions may save power; check coverage, network availability, receive, retry, and battery losses

Real numbers example (illustrative planning assumptions, not measured lifetimes or vendor quotes): For 100 soil sensors taking 5 readings/day over 5 years:

LoRaWAN: Model two AA batteries lasting 5-7 years and gateway backhaul at $50/year.
Cellular NB-IoT: Model 2-3 years of battery life and $200/year for a quoted fleet data plan; per-device SIM pricing may differ.
Wi-Fi: Model a powered sensor and $0 incremental data charge on an existing local network; electricity and network maintenance still cost money.

Confirm each estimate with measured current profiles, usable battery capacity, surveyed coverage, and local quotations before choosing a protocol.

39.14.1 Quick Knowledge Check: Gateway Architecture

Before proceeding, test your understanding of the gateway decisions you just made.

This section:

Checkpoint: Scale and Connectivity

You now know:

The vineyard example binds the decision to 500 sensors, 50 hectares, 5 readings/day, 20 bytes/reading, 50 kB/day, and 1.5 MB/month.
Gateway count is not a guess: the chapter warns that dense agriculture may need one gateway per 20-50 sensors rather than one gateway for the whole area.
The network must follow the constraint: LoRaWAN fits wide, low-rate field sensing; Bluetooth mesh or Wi-Fi extenders create power and coverage problems.

This section:

39.15 Step 4: Processing Layer

This section: Step 4: Processing Layer — Once connectivity is plausible, look for the next bottleneck: where the data should be reduced, buffered, or acted on before it reaches the cloud.

Once connectivity is plausible, look for the next bottleneck: where the data should be reduced, buffered, or acted on before it reaches the cloud.

Layer 3: Where to Process Data

Decide between edge, fog, and cloud processing.

39.16 Step 5: Application Layer

This section: Step 5: Application Layer

Layer 4: Business Applications

End-user applications and integrations.

This section:

Checkpoint: Processing Placement

You now know:

Processing location follows the bottleneck: latency, resilience, privacy, and bandwidth can justify edge-heavy design.
Raw vibration data at 500 sensors, 1 kHz, and 4 bytes/sample becomes 16 Mbps, which cannot fit a 2 Mbps cellular backhaul.
Edge processing is valuable only when it changes the evidence: filtering, FFT, anomaly detection, downsampling, buffering, or local control must reduce risk, not just add another layer.

This section:

39.17 Architecture Visualization

This section: Architecture Visualization

39.18 Cost Estimation

This section: Cost Estimation

39.19 Architecture Recommendations

This section: Architecture Recommendations

39.20 Architecture Patterns

This section: Architecture Patterns

Based on your selections, here are relevant architecture patterns:

Recommended Patterns for Your Application

39.21 Your Configuration Summary

This section: Your Configuration Summary — After visualization and recommendations, pause before treating the output as final.

After visualization and recommendations, pause before treating the output as final. The summary below is a candidate architecture to validate.

39.22 Common Pitfalls

This section: Common Pitfalls

1. Prioritizing Theory Over Measurement

Relying on theoretical models without profiling actual behavior can lead to designs that miss performance targets. Always measure the dominant bottleneck in your specific deployment environment — hardware variability, interference, and load patterns routinely differ from textbook assumptions.

2. Ignoring System-Level Trade-offs

Optimizing one parameter in isolation (latency, throughput, energy) without considering impact on others creates systems that excel on benchmarks but fail in production. Document the top three trade-offs before finalizing any design decision and verify with realistic workloads.

3. Skipping Failure Mode Analysis

Most field failures come from edge cases that work in the lab: intermittent connectivity, partial node failure, clock drift, and buffer overflow under peak load. Explicitly design and test failure handling before deployment — retrofitting error recovery after deployment can be costly and disruptive.

39.23 What’s Next

This section: What’s Next

Select protocols: Protocol Selector Wizard to refine connectivity choices based on your architecture constraints.
Plan your learning: Learning Paths to create a curriculum matched to your design goals.
Explore simulations: Simulation Playground to test your architecture virtually before committing to hardware.
Build a prototype: Capstone Projects to apply your architecture in a guided end-to-end project.
Deepen reference models: IoT Reference Models to compare your design against standard IoT architecture frameworks.
Reinforce decisions: IoT Games Hub to practise architecture trade-off reasoning through challenge rounds.

39.25 Concept Relationships

This section: Concept Relationships

IoT Architecture Planning Builds on: system design principles and layer models. Leads to: platform selection and protocol choice. Contrasts with: ad-hoc device deployment.
Edge vs Cloud Processing Builds on: computing fundamentals and latency requirements. Leads to: edge computing frameworks and fog architectures. Contrasts with: pure cloud-only architectures.
Gateway Architecture Builds on: protocol translation and network layers. Leads to: mesh networking and multi-protocol gateways. Contrasts with: direct device-to-cloud approaches.
Cost Estimation Builds on: TCO analysis and subscription models. Leads to: vendor negotiation and ROI calculation. Contrasts with: one-time hardware cost focus.
Redundancy Planning Builds on: system reliability and fault tolerance. Leads to: high-availability architectures and disaster recovery. Contrasts with: single-point-of-failure designs.

39.26 Knowledge Check

This section: Knowledge Check

39.26.1 Match Architecture Layers to Their Primary Responsibility

39.26.2 Order: IoT Architecture Design Process

39.26.3 Label the Diagram

39.27 Practice the Architecture Record

This section: Practice the Architecture Record

39.27.1 Code Challenge

39.27.2 Order the Steps

This section:

Checkpoint: Architecture Record

You now know:

Cost estimates combine hardware, cloud services, and connectivity; the chapter’s edge-filtering example moves 43.95 MB/month toward about 13.2 MB/month after 70% filtering.
Recommendations are warnings to test, not automatic approvals.
A complete architecture record names components, assumptions, data flow, security measures, and validation tasks in order.

This section:

39.27.3 Match the Concepts

39.28 Deep Dive: Place Computation Where the Constraint Lives

This section: Deep Dive: Place Computation Where the Constraint Lives — An IoT architecture spans sensing, networking, processing, cloud, and application layers, but the decision that shapes cost and behavior most is where computation runs.

An IoT architecture spans sensing, networking, processing, cloud, and application layers, but the decision that shapes cost and behavior most is where computation runs. The same analytics can execute on the device, at the edge through a nearby gateway, or in the cloud. Each placement trades a different set of properties.

Push work toward the device and you gain low latency, offline autonomy, and privacy, but you are limited by compute and battery. Push it to the cloud and you gain large-scale storage, analytics, and fleet-wide visibility, but you pay in latency, bandwidth, connectivity dependence, and exposure of raw data. The edge sits between those extremes.

Challenge Deep Dive: Place Computation Where the Constraint Lives with the visual in Figure 39.1: CLOUD LAYER names one checkpoint and Data Storage names another. Their relationship frames Use the edge, fog, and cloud tiers as a placement record: immediate sensing and actuation stay low, local aggregation and offline decisions sit in the fog or gateway layer, and fleet analytics plus management live in the cloud.

Three-tier IoT architecture showing edge devices and sensors, a fog layer for edge compute, aggregation, local cache, and gateways, and a cloud layer for storage, analytics, applications, and management. — Figure 39.1: Use the edge, fog, and cloud tiers as a placement record: immediate sensing and actuation stay low, local aggregation and offline decisions sit in the fog or gateway layer, and fleet analytics plus management live in the cloud.

At the top of Figure 39.1, the cloud layer groups storage, analytics, applications, and fleet management. Below it, the fog layer handles local processing and caching, while the edge/device layer contains sensors and actuators. Follow the connecting arrows to decide which work needs nearby computing and which can use central services.

39.28.1 Compare the Three Tiers

Property	On-device	Edge / gateway	Cloud
Latency	Lowest, often milliseconds	Low on the local network	Highest because of the internet round trip
Compute and storage	Very limited	Moderate	Effectively elastic
WAN bandwidth	Minimal when only results leave the device	Reduced by aggregation	Highest when raw data is uploaded
Privacy	Data can stay local	Data can stay on-site	Raw or detailed data may leave the premises
Offline operation	Can keep working	Can keep the site working	Depends on connectivity
Typical hardware / OS	Microcontroller, custom firmware	ARM-class board (Android, Linux, iOS)	x86-64, virtualized (Linux, etc.)

A supermarket cold-room monitor shows the split. It may read DS18B20 or SHT31 probes every few seconds, trigger a local buzzer when temperature crosses a food-safety threshold, and publish summaries to a cloud dashboard. The alarm decision belongs on the device or gateway because staff need it during an internet outage. The hourly trend, cross-site comparison, and maintenance report can live in the cloud because they need storage and fleet context more than millisecond timing.

Video analytics creates the same pressure. Streaming raw 1080p video to the cloud for hazard detection costs large amounts of bandwidth, adds latency, and ships sensitive footage off-site. Running the detection model on a gateway or camera means only a compact event travels upstream: timestamp, camera ID, confidence score, and a short retained clip when policy allows. The cloud still aggregates events and retrains models, but it should not sit in the real-time inference path.

39.28.2 Not All “Things” Are Alike

The on-device tier is not one category of hardware, and treating it as one is a common planning mistake. An embedded system, in Elicia White’s often-cited description, is “a computerized system that is purpose-built for its application” — unlike a phone, laptop, or server, its hardware and software are selected together around one job, and cost and energy typically dominate every other design choice.

That purpose-built nature is also why application domain changes the architecture more than the five-layer diagram alone suggests. Industrial automation deployments run on the order of thousands of devices per person in engineered, controlled environments with high-reliability control networks (WirelessHART, IEEE 802.15.4, RPL), because a missed control loop has a safety or production cost. Home and consumer IoT often use local radios such as Zigbee, Z-Wave, and Thread in less controlled environments, with network size and reliability requirements set by the application. Personal-area and wearable devices sit at tens of devices per person, trading fashion and battery life against instrumentation quality over Bluetooth LE or cellular, while general networked devices lean on Wi-Fi and plain TCP/IP. The same split shows up at the connectivity level: industrial IoT devices more often reach the global Internet directly over industry-specific protocols, while consumer IoT devices are more often limited to local, gateway-mediated communication over Bluetooth, Zigbee, or Wi-Fi. None of these profiles is more correct than another — they are different answers to the same “what does this thing need to survive its environment” question, and naming the domain profile first is what makes the connectivity table in Step 3 and the tier placement above resolve to a specific, defensible answer instead of a guess.

39.28.3 Hybrid Systems Need State Ownership

The device-vs-edge-vs-cloud choice is rarely all-or-nothing. Strong architectures are hybrids that place each function where it fits: filter and threshold on the device, aggregate and run time-critical logic at the edge, then store, analyze across sites, and train models in the cloud. Data gets smaller and less time-sensitive as it moves up the tiers.

A building HVAC system can run its per-room control loop on local controllers so comfort continues during WAN loss, have the site gateway aggregate zone data and enforce schedules, and send hourly summaries to the cloud for cross-building optimization and fault prediction. Each tier does the job it is suited for, and the architecture degrades gracefully instead of failing when the cloud link drops.

The hidden mechanism is ownership of state. The room controller owns immediate actuator state, the gateway owns site schedule and buffered telemetry, and the cloud owns fleet models and reporting history. Each handoff should name message schema, retry behavior, timestamp source, and stale-data rules. Without that ownership map, a hybrid design can become three partial systems that disagree during an outage.

Validate the placement by forcing failures: disconnect WAN, restart the gateway, replay delayed messages, and confirm the room controller still follows local limits while the cloud marks the site data as stale.

39.29 Summary

This section: Summary

The IoT Architecture Planner helps you design complete IoT systems:

5-layer design covering sensing, network, processing, cloud, and application
Data volume estimation based on sensors, frequency, and message size
Cost projection for hardware and ongoing services
Edge vs. cloud trade-offs with automatic recommendations
Pattern matching to relevant architecture approaches

Key Architecture Principles

Start small, scale up - Begin with proven patterns, add complexity as needed
Design for failure - Assume components will fail; build redundancy
Secure by design - Security is not an afterthought
Optimize data flow - Process at the edge when possible to reduce costs
Plan for evolution - Requirements change; choose flexible architectures

For Kids: Meet the Sensor Squad!

Temperature Terry is excited! “I want to build the BIGGEST IoT system ever!” he shouts.

the microcontroller laughs. “Whoa, slow down! Building a great IoT system is like planning an awesome school project. You need a plan!”

“First,” says the LED, “you pick what you want to SENSE — like temperature, motion, or light. That’s the sensing layer!”

“Then,” adds Max, “you figure out HOW to send your data. Wi-Fi? Bluetooth? LoRa? That’s the network layer!”

the battery pipes up: “And don’t forget about me! If you process data close to the sensors (at the ‘edge’), I last longer because you don’t have to send everything far away to the cloud!”

“So an IoT architecture is like a relay race,” Sammy says. “Sensors collect data, the network passes it along, the processor does something smart with it, the cloud stores it, and the app shows it to people!”

“Exactly!” cheers the whole Squad. “Layers working together — that’s architecture!”

Fun fact: The biggest IoT systems in the world (like smart cities) have MILLIONS of sensors all working together through these five layers!

Find help

Search reviewed answers

3 reviewed answers.

Where should I start in a module?

Open the module page from the sidebar to see its chapters in order. Use the module map to return to a topic you need.

Modules and paths

Reviewed 2026-10-16

What can I try when a project does not work?

Check the symptom, then work through the diagnostic steps. Keep the error message and the smallest example that reproduces it.

When you are stuck

Reviewed 2026-10-16

How do interactive examples work?

Use the interactive guide to check how examples and simulations work before changing your project.

Interactive examples guide

Reviewed 2026-10-16

Find help

39.1 In 60 Seconds

39.2 Start With the Story

39.3 Chapter Scope

39.4 IoT Architecture Planner

39.5 How It Works: Turn Requirements Into An Architecture

39.6 Incremental Examples

39.7 Quick Checks

39.8 Try It Yourself

39.9 See Also

39.10 Key Concepts

39.10.1 Key Takeaway

39.11 Prerequisites

39.12 Step 1: Define Your Application

39.13 Step 2: Sensing Layer

39.14 Step 3: Network Layer

39.14.1 Quick Knowledge Check: Gateway Architecture

39.15 Step 4: Processing Layer

39.16 Step 5: Application Layer

39.17 Architecture Visualization

39.18 Cost Estimation

39.19 Architecture Recommendations

39.20 Architecture Patterns

39.21 Your Configuration Summary

39.22 Common Pitfalls

39.23 What’s Next

39.24 Related Chapters

39.25 Concept Relationships

39.26 Knowledge Check

39.26.1 Match Architecture Layers to Their Primary Responsibility

39.26.2 Order: IoT Architecture Design Process

39.26.3 Label the Diagram

39.27 Practice the Architecture Record

39.27.1 Code Challenge

39.27.2 Order the Steps

39.27.3 Match the Concepts

39.28 Deep Dive: Place Computation Where the Constraint Lives

39.28.1 Compare the Three Tiers

39.28.2 Not All “Things” Are Alike

39.28.3 Hybrid Systems Need State Ownership

39.29 Summary

Find help