Design Patterns Module Guide
Your guide: Blueprint Bina
“Use a pattern when it makes ownership, failure, and change easier to explain—not because its name sounds architectural.”
Follow Blueprint Bina as a working demo hides an ownerless handoff where a field message is lost.
The demo works, but one field message is lost.
No one owns the gap between those parts.
Test one likely cause along the same path.
Choose a small fix and check its new risk.
Diagnose Before You Name a Pattern
A design pattern is a reusable answer to a recurring force, not a label to paste onto a diagram. Start by naming what is failing or becoming costly: unclear ownership, coupled releases, slow calls, duplicate work, cascading failure, unsafe device transitions, or a deployment boundary that cannot be operated. Only then decide whether service boundaries, an API contract, resilience controls, orchestration, or a state machine addresses the cause.
Carry one scenario through the route: a building-management platform grew from one service into a tightly coupled application that ingests telemetry, evaluates alarms, dispatches work orders, commands HVAC equipment, and reports compliance. A slow work-order API now delays alarm processing; retries multiply commands; releases require all teams at once; and controllers can jump between states that should be impossible. Your task is to move from anti-pattern evidence to the smallest justified pattern.
Learning Objectives
By the end of the route, you should be able to diagnose architecture anti-patterns from observable coupling, ownership, data, deployment, and failure evidence; define service boundaries around capabilities and change responsibility; and specify API contracts with identity, versioning, idempotency, discovery, timeout, and compatibility behavior. You should be able to explain why microservices can amplify rather than remove a poorly understood boundary.
You should also be able to select bounded retries, timeouts, circuit breakers, bulkheads, fallbacks, and idempotency from a failure contract; distinguish container packaging from orchestration responsibility; and model device behavior as explicit states, events, guards, actions, timeouts, and safe recovery. For every pattern, you should be ready to state the force it addresses, the new cost it introduces, and the evidence that would trigger revision.
Before You Start
You should already be able to draw an IoT path from device through network, service, storage, and user action. If boundaries and quality attributes are unfamiliar, begin with Diagnosing IoT Architecture Anti-Patterns and Choosing an IoT Architecture Pattern. Basic HTTP or messaging vocabulary helps with the API chapter; basic process-state reasoning helps with the final chapter.
You do not need Kubernetes, a service mesh, or a microservice estate. This module explains when those mechanisms answer a demonstrated need and when they add operational surface. The prerequisite boundary is an explicit problem statement, current architecture, responsible owners, failure evidence, and a change constraint. Without those, pattern selection becomes fashion rather than engineering.
A Worked Route Through the Module
First, turn anti-pattern symptoms into a boundary decision
Start with Diagnosing IoT Architecture Anti-Patterns. For the building platform, record a change-coupling matrix, shared database writes, cross-team release dependencies, latency and failure propagation, duplicated domain rules, and commands with unclear ownership. Separate a large component from a badly bounded component: size alone is not the diagnosis. The key finding is that alarm evaluation and work-order dispatch change for different reasons yet share synchronous execution and data ownership.
Move to Service Boundaries and Decomposition only when the diagnosis supports separation. Define an alarm capability that owns alarm state and policy, and a work-order capability that owns assignment and lifecycle. Decide what remains a modular monolith, what crosses a message or API boundary, who owns each data record, and how an end-to-end incident is traced. If the same team deploys everything together and the boundary has no independent scaling, security, or change need, an internal module may be the safer pattern.
Next, make the boundary consumable
Use API Contracts and Service Discovery to specify the handoff. Give an alarm a stable identifier, schema version, creation and event times, severity, asset, evidence links, and idempotency key. Define authentication and authorization, request and response semantics, timeout, pagination or streaming where relevant, compatibility policy, discovery mechanism, health signal, deprecation window, and error contract. A service boundary without a governed contract simply moves hidden coupling onto the network.
Choose synchronous calls only where the caller needs an immediate answer and can bound the wait. Publish an alarm-created event when work-order dispatch may continue independently and replay matters, but record ordering, duplication, consumer lag, and failure ownership. Do not use an event to avoid naming an owner or an API to pretend a distributed transaction is local.
Then, contain failure instead of multiplying it
Continue to Retries, Timeouts, and Circuit Breakers. Give the work-order call a timeout shorter than the alarm-processing budget, retry only transient and idempotent operations with exponential backoff and jitter, cap the attempt budget, and open a circuit when continued calls would worsen recovery. A bulkhead prevents dispatch saturation from consuming alarm resources; a fallback queues a work order for later review without falsely reporting completion.
Test the retry multiplication across every layer. A browser retrying a gateway that retries a service that retries a database can turn one action into many commands. Place retry ownership at the layer with enough context, keep command idempotency end to end, and expose circuit, queue, fallback, and recovery state to operators. Resilience patterns trade immediacy and simplicity for controlled degradation; record that trade.
Use orchestration only for an operating problem
Open Container Orchestration at the Edge when the services have a real placement, rollout, health, scaling, secret, or recovery need. Packaging the alarm evaluator in a container can make its runtime repeatable; orchestration adds scheduling, desired state, probes, updates, rollback, and resource policy. It does not define the domain boundary, make a non-idempotent command safe, or repair a chatty synchronous design.
For the building estate, decide which workload must remain at the edge during cloud loss, which state may move, how rollout avoids losing alarm coverage, what readiness means, and who can roll back. Compare that requirement with the operational skill and footprint available. A supervised process or small edge runtime may be more resilient than a cluster the team cannot observe or recover.
Finish with explicit device behavior
Use State Machines for Device Behavior for the HVAC controller. Define states such as Off, Starting, Running, Degraded, Stopping, and Fault; events such as start request, sensor timeout, safe threshold, overload, and reset; guards that prevent unsafe transitions; entry and exit actions; and timers for start-up and recovery. Reject the impossible jump from Fault directly to Running without diagnosis and reset evidence.
Join the state machine to the earlier patterns carefully. An API requests a transition; authorization decides whether the caller may request it; the state machine decides whether it is valid now; resilience controls bound delivery; and orchestration manages the service process, not the physical machine's safety state. Preserve command ID, old state, event, guard result, new state, action, timestamp, and owner in one trace.
Activities and Interactives
Use the Architecture Pattern Matcher after the anti-pattern diagnosis and before decomposition. Enter the building platform's team, latency, scaling, ownership, and compliance constraints, predict the recommendation, and explain any disagreement. Then sketch two alternatives—modular monolith and separated alarm/work-order capabilities—and compare their deployment, data, failure, and observability costs.
Place chapter checks beside the decision they test: contract and discovery checks after API design, failure injections after resilience, placement and rollout checks after orchestration, and a transition table plus invalid-event trace after state machines. Keep one architecture decision record across the route with symptom, evidence, chosen pattern, rejected alternative, new failure mode, owner, proof, rollback, and retest trigger.
Quick Route Check
A slow work-order API delays alarm processing and repeated retries create duplicate dispatches. Should the team begin by moving both components into Kubernetes?
Reveal the route
No. First diagnose the coupling and ownership failure. Define alarm and work-order boundaries and an idempotent handoff contract; then add bounded timeout, retry, circuit, queue, and fallback behavior. Consider orchestration only after naming a deployment, placement, health, scaling, or rollout problem it must solve. Use a state machine separately where device transitions—not service deployment—need explicit guards and recovery.