Design Patterns · Study deck

IoT Architecture Anti-Patterns: Scenarios and Selection

The anti-patterns are recognizable on paper, but a real warehouse or grid mixes devices, networks, edge services, platforms, and applications.

Blueprint Bina is your guide for this deck.

models
Blueprint Bina, the module guide, in a scene from this chapter.
iotclass.org

After studying this chapter

Learning objectives

You will be able to:

  • Explain: Any branch answered from an assumption rather than a measurement belongs in that record with an owner, a test, and the deployment milestone before which the uncertainty must be resolved.
  • Explain: The models group responsibilities differently, but the running narrative remains stable: choose the framing that makes ownership, data flow, and validation boundaries clearest for the system under review.
  • Explain: The review should name the payload, latency, retention, access, and ownership evidence at those transitions so that a labelled layer is not mistaken for a verified responsibility.
  • apply a reference model to a warehouse or grid scenario
iotclass.org

Major section

Architecture Scenarios

Each scenario asks which layer should own local control, buffering, abstraction, analytics, and operations handoff.

  • Star topology with central hub: Zigbee coordinator or Z-Wave controller acts as network center.
  • Communication range: Zigbee mesh extends effective range; PoE supports 100m cable runs.
  • Hub failure is easy to identify and device faults are isolated from other spokes.

Numbers to remember

100mPoE supports 100m cable runs.

Why it matters

Single cable for data and power reduces retrofit complexity for mains-powered devices.

iotclass.org

Major section

Scenario: Automated Warehouse Using the 7-Level Model

Challenge:: A warehouse automation team has mobile robots, conveyors, scanners, environmental sensors, and human safety zones.

  • The result is brittle integration, high latency for local safety decisions, and duplicated device-specific logic across dashboards.
  • Safety devices such as light curtains, emergency stops, and human-presence sensors.
  • Applications consume stable APIs rather than vendor schemas.

Why it matters

Safety and motion decisions stay local because cloud round trips are too slow and too failure-prone.

iotclass.org

Major section

Scenario: Automated Warehouse Using the 7-Level Model (continued)

Edge nodes buffer events when the cloud link is unavailable.

  • Level 7 (Collaboration & Processes):: Human-machine coordination.
  • Site teams share validated rules and dashboards across facilities.
  • Lower latency: local controllers make safety and routing decisions without cloud dependency.
  • Cleaner integration: new equipment requires an adapter, not a dashboard rewrite.
iotclass.org

Major section

Scenario: Smart Grid Monitoring Using an IoT-A Style Model

Digital twin value: virtual entities allow analysis by asset, not just by sensor stream.

  • Challenge:: A utility has smart meters, feeder sensors, transformers, substations, and customer-facing applications.
  • Multiple device vendors and regulatory environments make direct device-to-application integration expensive and difficult to govern.
  • Privacy controls before analytics.

Why it matters

Digital twin enables "what-if" simulations: "If transformer T-4521 fails, which transformers will be overloaded?".

iotclass.org

Major section

Scenario: Smart Grid Monitoring Using an IoT-A Style Model (continued)

Interoperability: service contracts reduce vendor-specific application code.

  • Governance: privacy and access controls are applied consistently across services.
  • IoT-A's virtual entity layer is powerful for physical infrastructure digital twins - transformers, substations represented as software objects.
  • Cross-cutting governance is easier to maintain than per-layer security bolt-ons.
iotclass.org

Major section

Architecture Selection Decision Tree

When designing an IoT system, choosing the right architecture pattern is critical.

  • The scenario evidence now has to produce a dominant deployment pattern.
  • A: Yes on local response or offline operation should keep processing near the device; a: No moves the review toward aggregation and cloud-scale needs.

Key terms

Hybrid
Hybrid is not a licence to deploy everywhere; it is the result of applying latency, connectivity, privacy, energy, and operating evidence to each responsibility.
IoT Architecture Decision Tree: Selecting the Right Pattern
IoT Architecture Decision Tree: Selecting the Right Pattern
iotclass.org

Major section

Architecture Selection Decision Tree (continued)

Any branch answered from an assumption rather than a measurement belongs in that record with an owner, a test, and the deployment milestone before which the uncertainty must be resolved.

  • Latency Often 100 ms to seconds Scale Very high Connectivity Requires backhaul Complexity Medium.
  • Latency Varies by duty cycle and route Scale Very high when planned well Connectivity Mesh or clustered Complexity High.
  • Hybrid is not a licence to deploy everywhere; it is the result of applying latency, connectivity, privacy, energy, and operating evidence to each responsibility.
iotclass.org

Major section

Visual: 7-Level IoT Reference Model

The review should name the payload, latency, retention, access, and ownership evidence at those transitions so that a labelled layer is not mistaken for a verified responsibility.

  • That sequence reconnects the gallery to the chapter's core rule: each boundary should own a distinct transformation or contract.
Cisco 7-level IoT reference model architecture
Cisco 7-level IoT reference model architecture
iotclass.org

Major section

Visual: Comparing Reference Models

The comparison lets the reader align responsibilities across frameworks before evaluating operating trade-offs.

  • The models group responsibilities differently, but the running narrative remains stable: choose the framing that makes ownership, data flow, and validation boundaries clearest for the system under review.
Comparison of major IoT reference models
Comparison of major IoT reference models
iotclass.org

Major section

Decision Framework: Selecting IoT Architecture Layer Deployment

This framework helps decide where each layer should run.

  • Sensors and actuators must be physically present.
  • Business workflows, maintenance tickets, reporting, and cross-site learning usually live in cloud systems, but they depend on trustworthy lower-layer data.
  • Privacy-sensitive data: medical sensors, facial recognition (process locally, never send raw data).

Why it matters

The 7-layer IoT reference model allows flexible deployment of processing across edge, fog, and cloud.

iotclass.org

Major section

Common Mistake: Cloud-Only Architecture with High-Frequency IoT Devices

Worse, during cellular dead zones, all location data was lost (no local buffering).

  • "Cloud is infinitely scalable" mindset ignores per-message pricing (AWS IoT: $1/million messages + bandwidth).
  • But trackers also send telemetry (speed, fuel, diagnostics) → 3x messages → $29,808/month.
  • Detect "significant movement" (>100m from last reported position) → send update.
  • Aggregate fleet data: "Zone 5 has 12 active trucks" instead of 12 separate messages.
iotclass.org

Deck summary

Key takeaways

Each scenario asks which layer should own local control, buffering, abstraction, analytics, and operations handoff.

  • Challenge:: A warehouse automation team has mobile robots, conveyors, scanners, environmental sensors, and human safety zones.
  • Edge nodes buffer events when the cloud link is unavailable.
  • Digital twin value: virtual entities allow analysis by asset, not just by sensor stream.
  • Interoperability: service contracts reduce vendor-specific application code.
iotclass.org

Retrieval practice

Recall check 1 of 4

Blueprint Bina says: answer from memory, then check your reasoning.

Q1An agricultural company is deploying soil moisture sensors across 10,000 acres of farmland. Sensors are solar-powered, data rates are low (one reading every 15 minutes), and there's no reliable cellular coverage. Real-time response is NOT required - daily irrigation decisions are sufficient. Which architecture pattern is MOST appropriate?

AEdge Computing - for real-time local processing
BCloud-only - sensors send directly to cloud via cellular
CLPWAN (LoRaWAN) with periodic sync to cloud
DWireless Sensor Network (WSN) with mesh topology
Show answer

Answer: C Correct!

iotclass.org

Retrieval practice

Recall check 2 of 4

Blueprint Bina says: answer from memory, then check your reasoning.

Q2Place each reference-model responsibility where it lives so you can expose missing ownership at every system handoff.

ADevice
BData
COperations
DApplication
Show answer

Answer: A Device and connectivity establish the field boundary, data and edge establish processing ownership, and application and operations close the decision-and-feedback loop so you can review the whole system.

Q3Complete the anti-pattern classifier used during an IoT reference-model review:

Aif symptom == "cloud_outage":
Bif symptom = "cloud_outage":
Cif symptom in cloud_outage:
Dif "cloud_outage" = symptom:
Show answer

Answer: A Cloud outages point to a cloud-only dependency, schema breaks point to missing abstraction or direct database coupling, and relay drain points to an energy-hotspot routing problem.

iotclass.org

Retrieval practice

Recall check 3 of 4

Blueprint Bina says: answer from memory, then check your reasoning.

Q4An IoT startup sends ALL sensor data directly to the cloud for processing. During an internet outage, the entire system goes offline. Which anti-pattern did they fall into?

AEnergy hotspot anti-pattern in relay-node routing
BDirect database access anti-pattern in app integration
COver-segmentation anti-pattern in network partitioning
DCloud-only anti-pattern with no local edge fallback
Show answer

Answer: D The cloud-only anti-pattern is the most common IoT architecture failure.

iotclass.org

Retrieval practice

Recall check 4 of 4

Blueprint Bina says: answer from memory, then check your reasoning.

Q5A production IoT system processes 95% of sensor data at the edge and sends only aggregated summaries to the cloud. What architecture pattern is this, and what is its primary benefit?

APure edge architecture with no cloud dependency
BFog architecture with all processing at intermediate nodes
CEdge-heavy hybrid architecture with lower cloud load
DCloud-first architecture with temporary edge caching
Show answer

Answer: C Most production IoT systems are hybrid.

iotclass.org

Print reference

Answers

Answer key.

  1. C · Correct!
  2. A · Device and connectivity establish the field boundary, data and edge establish processing ownership, and application and operations close the decision-and-feedback loop so you can review the whole system.
  3. A · Cloud outages point to a cloud-only dependency, schema breaks point to missing abstraction or direct database coupling, and relay drain points to an energy-hotspot routing problem.
  4. D · The cloud-only anti-pattern is the most common IoT architecture failure.
  5. C · Most production IoT systems are hybrid.
iotclass.org