22 IoT Design Patterns: Gateways, Twins, and Commands
22.1 Start With the Decision
A gateway can translate a link, but it can also hide stale state or failed commands. Its exact duty must be bounded.
22.2 Route Overview
This is part 2 of 2. Review IoT Design Patterns: Responsibility Boundaries for the preceding evidence.
22.3 Learning Objectives
- Compare gateway, digital twin, command, and observer patterns.
- Combine patterns without duplicating state ownership.
22.4 Chapter Roadmap
- Gateway Pattern
- Digital Twin Pattern
- Command Pattern
- Observer Pattern
- Combining Patterns Without Drift
- Shared Building Controls Pattern Check
- Model-Driven Design
- Pattern And Component Record
- Incremental Examples
- Worked Review: Shared Building Controls
- Worked Review: Replaceable Field Device
- Common Findings
- Review Checklist
- Try It Now
- Micro-Exercise: Find the Pattern Drift
- Concept Check: Pattern Readiness
- Match Patterns to Duties
- Concept Check: Order the Pattern Review
- Summary
- Key Takeaway
- See Also
- What’s Next
22.5 Gateway Pattern
Use the Gateway pattern when a boundary must translate, filter, buffer, secure, or locally decide on behalf of constrained or heterogeneous devices.
Common Gateway responsibilities include:
translating between device-side and application-side protocols. normalizing payloads from devices with different formats. buffering readings when upstream paths are unavailable. performing local checks that should not wait for a remote service. enforcing a boundary between local device networks and remote services. exposing support evidence about local connectivity, queue state, and last successful sync.
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.
Before deciding how Zigbee shapes gateway pattern, inspect Figure 22.1 beside Key Benefits. Together, Zigbee and Key Benefits frame the gateway pattern claim: 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.
Trace Figure 22.1 from Zigbee toward Key Benefits; that hand-off expresses 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. For gateway pattern, Zigbee supplies visible evidence; Key Benefits constrains the decision. In Figure 22.1, retain Zigbee beside Key Benefits so gateway pattern remains explicit.
22.6 Digital Twin Pattern
Use the Digital Twin pattern when the system needs an explicit representation of a physical thing, space, asset, or process that multiple services can read, compare, simulate, or reason about.
A useful digital twin records:
identity of the represented thing. current known state and freshness. source of each state update. confidence or validation status where needed. relationship to commands and physical outcomes. stale-state and conflict behavior. owner of the model and schema changes.
Do not use a digital twin as a label for any database row. 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.
Before deciding how Telemetry shapes digital twin pattern, inspect Figure 22.2 beside Cloud Digital Twin. Together, Telemetry and Cloud Digital Twin frame the digital twin pattern claim: digital twin pattern linking a physical iot sensor or actuator to a cloud representation and simulation or analytics operations.
Read Telemetry alongside Cloud Digital Twin in Figure 22.2; their named relationship makes digital twin pattern linking a physical iot sensor or actuator to a cloud representation and simulation or analytics operations concrete. For digital twin pattern, Telemetry supplies visible evidence; Cloud Digital Twin constrains the decision. In Figure 22.2, retain Telemetry beside Cloud Digital Twin so digital twin pattern remains explicit.
22.7 Command Pattern
Use the Command pattern when actions must be represented as explicit requests that can be validated, authorized, queued, retried, canceled, rejected, audited, or explained.
Command decisions should make these fields visible:
requested action. target component or physical effect. issuer and permission. precondition for acceptance. execution state. acknowledgement rule. retry, cancellation, and timeout behavior. reason for rejection or partial completion. record needed for support and review.
This is especially important when a command crosses a physical boundary. A user-facing “turn off” action, a maintenance reset, or a scheduled actuator change should not disappear into a direct method call unless the system can still explain whether the request was accepted, executed, delayed, or rejected.
Before deciding how Lights shapes command pattern, inspect Figure 22.3 beside INVOKER. Together, Lights and INVOKER frame the command pattern claim: command pattern for iot showing mobile app and automation rules enqueueing commands, an invoker executing them on lights, thermostat, and locks, and a command history supporting undo.
Read Lights alongside INVOKER in Figure 22.3; their named relationship makes command pattern for iot showing mobile app and automation rules enqueueing commands, an invoker executing them on lights, thermostat, and locks, and a command history supporting undo concrete. For command pattern, Lights supplies visible evidence; INVOKER constrains the decision. In Figure 22.3, retain Lights beside INVOKER so command pattern remains explicit.
22.8 Observer Pattern
Use the Observer pattern when one event needs to reach multiple subscribers without making the publisher know every subscriber’s implementation.
Observer reviews should define:
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. It moves responsibility into event contracts. If subscribers interpret the same event differently, the event needs a clearer definition, a versioned schema, or a more specific event type.
Before deciding how subscribe() shapes observer pattern, inspect Figure 22.4 beside Notification Workflow. Together, subscribe() and Notification Workflow frame the observer pattern claim: observer pattern for an iot sensor hub publishing motion events to a mobile app, cloud logger, and alarm system through explicit notify and subscribe relationships.
Read subscribe() alongside Notification Workflow in Figure 22.4; their named relationship makes observer pattern for an iot sensor hub publishing motion events to a mobile app, cloud logger, and alarm system through explicit notify and subscribe relationships concrete. For observer pattern, subscribe() supplies visible evidence; Notification Workflow constrains the decision. In Figure 22.4, retain subscribe() beside Notification Workflow so observer pattern remains explicit.
22.9 Combining Patterns Without Drift
IoT systems often combine patterns. 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.
Combine patterns only when each one owns a different responsibility:
Gateway owns boundary translation, buffering, or local fallback. Digital Twin owns state representation and freshness. Command owns physical action requests and execution records. Observer owns event distribution and subscriber decoupling. Components own replaceable interfaces. Models own consistent generation across similar deployments.
Pattern drift appears when the same responsibility is claimed in several places. Examples include a gateway and cloud service both claiming state authority, a command queue and direct API both controlling the same actuator, or subscribers silently treating events as commands.
Combining patterns is safe only when each one owns a distinct problem. Figure 22.5 provides the responsibility test needed to prevent a gateway, twin, command path, or component boundary from becoming a vague all-purpose abstraction.
The cards in Figure 22.5 assign Gateway to boundary translation, buffering, and local fallback, while Digital Twin owns state representation and freshness. Command is narrower still: it owns physical action requests and execution records; Observer distributes events without taking over command semantics. Component protects replaceable interfaces at a boundary, and Model-driven generation maintains consistency across deployments. A combined design remains reviewable only if those ownership statements stay non-overlapping, which is the chapter’s test for pattern drift.
For shared IoT controls such as lighting, access, booking, or comfort systems, test the pattern combination with these questions:
Gateway: who can still act when the internet path is unavailable? Digital twin: which displayed state is authoritative, and how stale can it be before it must be marked? Command: which commands need confirmation, undo, timeout, or escalation? Observer: who is notified about routine state, conflict, maintenance, and safety events? Model-driven design: which shared rules live in the model rather than in one screen or device?
The design is weak if it works only for the first user and not for residents, visitors, facilities staff, and support teams.
22.10 Model-Driven Design
Model-driven design uses a shared model to generate consistent artifacts. It can fit IoT work when many deployments share structure but vary by device type, location, permission, topic, threshold, interface, or support workflow.
Good model-driven design has:
a reviewed source model. generated artifacts with clear ownership. traceability from generated output back to model fields. validation that catches invalid model combinations. a manual override policy. change conditions when the model, generator, or target environment changes.
Avoid model-driven design when the model is less clear than the generated output. The model should reduce drift, not hide design decisions behind a generator.
Before deciding how Backend shapes model-driven design, inspect Figure 22.6 beside Sensor drivers, GPIO. Together, Backend and Sensor drivers, GPIO frame the model-driven design claim: model-driven development workflow showing a domain model transformed into a platform-independent model, code generator, and platform-specific arduino, esp32, and cloud backend implementations.
Trace Figure 22.6 from Backend toward Sensor drivers, GPIO; that hand-off expresses model-driven development workflow showing a domain model transformed into a platform-independent model, code generator, and platform-specific arduino, esp32, and cloud backend implementations. For model-driven design, Backend supplies visible evidence; Sensor drivers, GPIO constrains the decision. In Figure 22.6, retain Backend beside Sensor drivers, GPIO so model-driven design remains explicit.
22.11 Pattern And Component Record
Before deciding how behavior shapes pattern and component record, inspect Figure 22.7 beside Change condition. 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.
In the diagram, check behavior and Change condition separately in Figure 22.7; together they make pattern and component review record: ten fields to preserve for a pattern choice auditable. For pattern and component record, behavior supplies visible evidence; Change condition constrains the decision. In Figure 22.7, retain behavior beside Change condition so pattern and component record remains explicit.
scenario and product promise. component boundary. selected pattern and rejected alternative. interface contract. state authority. command or event behavior. failure and degraded-mode behavior. owner. open issue. change condition.
This record should be short enough to maintain and specific enough to test. If the record becomes vague, the pattern choice is not ready.
22.12 Incremental Examples
22.12.1 Split Device and App Duties
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.
22.12.2 Gateway and Twin Boundaries
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. The review should name which service owns desired versus reported state, what happens when the gateway buffers messages during internet loss, how duplicate observer events are handled, and which support view can explain stale or conflicting room state.
22.12.3 Generate Contracts from Models
A campus deployment may use model-driven design to generate AsyncAPI channels, JSON Schema payloads, OpenAPI paths, dashboard labels, support checklist fields, and hardware-in-loop test fixtures from one source model. This only helps if model owners, schema versions, rollout cohorts, field overrides, gateway firmware versions, and support diagnostics are explicit. The advanced review should reject hand-edited generated output when it breaks traceability.
22.14 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.
A pattern review might accept:
- a component boundary around the field device interface
- a gateway adapter that normalizes the replacement device payload
- a digital twin field for diagnostic state only if support workflows use it
- command records for calibration or reset actions
- observer events for replacement, calibration, diagnostic change, and rejected command outcomes
- a model-driven template if the same replacement process repeats across deployments
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.
22.15 Common Findings
During review, pattern chapters often reveal these defects:
The design names a pattern but does not assign a responsibility. The component boundary hides state ownership. 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. Observers receive events without schema, ordering, or duplicate-event rules. The same physical action can be triggered through both direct calls and queued commands. The generated model output cannot be traced back to the source model. Support teams cannot tell whether the issue is device, gateway, app, cloud, or user-context related.
22.16 Review Checklist
Use this checklist before accepting a pattern design:
Is the pattern solving a reviewed problem rather than adding vocabulary? Is the component boundary small enough to test and replace? Is the interface contract explicit? Is state authority visible? Are command acceptance and rejection visible? Are event meanings and subscribers visible? Is stale, duplicate, offline, and degraded behavior documented? Is the tradeoff recorded? Does a named owner maintain the interface and pattern decision? Is there a change condition for new devices, new states, new subscribers, new commands, or new product promises?
22.17 Try It Now
Choose one IoT pattern choice and write a one-row responsibility review:
| Field | Your answer |
|---|---|
| Product promise | What user, support, or operations promise depends on this pattern? |
| Boundary | Which device, gateway, service, model, app, or support surface owns the responsibility? |
| Interface contract | MQTT topic, REST path, AsyncAPI channel, JSON Schema payload, command field, or event schema. |
| Failure behavior | Stale state, rejected command, duplicate event, queue overflow, offline fallback, or degraded mode. |
| Change condition | New device type, subscriber, command, schema, deployment model, or product promise that reopens the choice. |
22.18 Micro-Exercise: Find the Pattern Drift
For each symptom, name the likely drift:
The gateway and cloud service both rewrite reported device state. A dashboard treats a digital-twin desired value as measured state. Two subscribers interpret the same observer event as different commands.
22.19 Concept Check: Pattern Readiness
22.20 Match Patterns to Duties
22.21 Concept Check: Order the Pattern Review
22.22 Summary
IoT design patterns and components help teams assign responsibility in systems that cross devices, gateways, apps, services, people, and physical environments. Gateway, Digital Twin, Command, Observer, component-based design, and model-driven design are useful when they make interfaces, state, commands, events, generated artifacts, failure behavior, owners, and change conditions easier to inspect.
Do not approve a pattern because it sounds established. Approve it when the boundary, evidence, tradeoff, owner, and failure behavior are visible.
22.23 Key Takeaway
Component patterns should clarify boundaries, state ownership, command paths, event flows, and user-visible recovery behavior.
22.24 See Also
IoT Pattern Selection Assessment shows how to assess pattern fit before implementation. IoT Architecture Model Selection defines the boundary that pattern choices must respect. Calm Technology Attention Policy keeps attention, service, product, and platform effects visible. Connected Device Fundamentals explains device roles that become component boundaries. Reference Architecture Responsibility Record provides broader architecture vocabulary for the next review.
22.25 What’s Next
Continue to Reference Architecture Responsibility Record to review the larger architecture models that pattern and component choices must fit.
22.26 Continue Your Route
This final part closes the route from Gateway Pattern through What’s Next. Return to IoT Design Patterns: Responsibility Boundaries or continue from the ux-design module index.