UX Design · Study deck

IoT Design Patterns: Gateways, Twins, and Commands

A gateway can translate a link, but it can also hide stale state or failed commands.

UX Uma is your guide for this deck.

design-patternscomponent-designgateway-pattern

UX Uma, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain: A building-control system might use a gateway for local device translation, a digital twin for room state, commands for actuator requests, and observers for events consumed by apps, dashboards, logs, or support tools.
Explain: If all real responsibility remains hidden in remote services, the design still needs to say what happens when connectivity fails, state is stale, or a device reports data the gateway cannot interpret.
Explain: event name and meaning. Publisher responsibility. Subscriber responsibility. Delivery expectation. Duplicate, late, or missing event behavior. Event ordering assumptions. Unsubscribe or permission rules. Support evidence for event delivery.

Major section

Gateway Pattern

The Gateway pattern is weak when it becomes an unnamed pass-through.

If all real responsibility remains hidden in remote services, the design still needs to say what happens when connectivity fails, state is stale, or a device reports data the gateway cannot interpret.

IoT Gateway pattern connecting constrained Zigbee, BLE, and MQTT devices to cloud APIs, data stores, and analytics through protocol translation, data aggregation, and edge processing.

Major section

Digital Twin Pattern

The pattern matters when the representation changes how the system reasons about the real world.

If a simple state record is enough, the added twin model may create extra synchronization and support work without improving the design.

Digital Twin pattern linking a physical IoT sensor or actuator to a cloud representation and simulation or analytics operations.

Major section

Observer Pattern

event name and meaning. Publisher responsibility. Subscriber responsibility. Delivery expectation. Duplicate, late, or missing event behavior. Event ordering assumptions. Unsubscribe or permission rules. Support evidence for event delivery.

The Observer pattern does not remove responsibility.
If subscribers interpret the same event differently, the event needs a clearer definition, a versioned schema, or a more specific event type.

Major section

Combining Patterns Without Drift

A building-control system might use a gateway for local device translation, a digital twin for room state, commands for actuator requests, and observers for events consumed by apps, dashboards, logs, or support tools.

Command owns physical action requests and execution records.
Pattern drift appears when the same responsibility is claimed in several places.

IoT design pattern selection map showing six pattern families and the responsibility each one owns.

Major section

Pattern And Component Record

Together, behavior and: Change condition frame the pattern and component record claim: pattern and component review record: ten fields to preserve for a pattern choice.

For pattern and component record, behavior supplies visible evidence;: Change condition constrains the decision.
This record should be short enough to maintain and specific enough to test.

Pattern and component review record: ten fields to preserve for a pattern choice.

Major section

Incremental Examples

A beginner review can use a single smart plug with one relay, one mobile control, and one status card.

The component boundary should say whether the device firmware, mobile app, MQTT retained topic, or cloud service owns on/off state, pending command state, offline state, and last-seen time.
The pattern choice may be simple: a command record for relay changes and an observer event for state updates.
A shared room-control system may use a gateway to translate Zigbee or BLE device reports into MQTT topics and a digital twin to represent room occupancy, freshness, confidence, and actuator relationships.

Major section

Worked Review: Shared Building Controls

Scenario: a shared building needs occupancy-aware lighting and ventilation.

Facility staff need local operation during connectivity loss, occupants need understandable feedback, and support staff need evidence when rooms behave unexpectedly.
Command for actuator requests so lighting and ventilation changes have acceptance, execution, rejection, and support records.
The review is incomplete until it also records stale-state behavior, conflicting sensor evidence, command rejection behavior, and who owns each interface.

Major section

Worked Review: Replaceable Field Device

Scenario: a field maintenance team needs to replace a sensor device without rewriting the app, support guide, and cloud data model.

The replacement device measures the same phenomenon but reports additional diagnostics.
The design should reject any pattern that hides compatibility.
If the replacement needs a new payload, permission, diagnostic state, or support action, that change must appear in the interface record and change condition.

Major section

Common Findings

The design names a pattern but does not assign a responsibility.

A gateway translates data but has no documented offline behavior.
A digital twin exists but the stale-state rule is missing.
Commands can be sent but not clearly accepted, rejected, retried, or audited.
The same physical action can be triggered through both direct calls and queued commands.

Deck summary

Key takeaways

The Gateway pattern is weak when it becomes an unnamed pass-through.

The pattern matters when the representation changes how the system reasons about the real world.
event name and meaning. Publisher responsibility. Subscriber responsibility. Delivery expectation. Duplicate, late, or missing event behavior. Event ordering assumptions. Unsubscribe or permission rules. Support evidence for event delivery.
A building-control system might use a gateway for local device translation, a digital twin for room state, commands for actuator requests, and observers for events consumed by apps, dashboards, logs, or support tools.
A beginner review can use a single smart plug with one relay, one mobile control, and one status card.

Retrieval practice

Recall check

UX Uma says: answer from memory, then check your reasoning.

Q1A team chooses a gateway, digital twin, and observer event stream for a shared building system. The design shows data flow, but it does not say who owns room state, what happens when state is stale, or how actuator commands are accepted or rejected. What should the reviewer do?

AApprove the design because established IoT pattern names are visible and the data-flow diagram is easy to follow.

BAsk the team to add another pattern label so every responsibility appears covered before implementation starts.

CHold until state owner, stale-state rule, command acceptance, failure behavior, owners, and change conditions are recorded.

DRemove the gateway because the digital twin can hold building state and make the diagram look simpler.

Show answer

Answer: C Pattern review accepts evidence-bound responsibilities, not pattern vocabulary.

Print reference

Answers

Answer key.

C · Pattern review accepts evidence-bound responsibilities, not pattern vocabulary.