Design Patterns · Study deck

Service Boundaries and Decomposition

Telemetry means records sent from a system so its state can be watched.

Blueprint Bina is your guide for this deck.

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

After studying this chapter

Learning objectives

You will be able to:

Compare modular monoliths, SOA integration, and microservices without treating any of them as a default.
Identify IoT service boundaries from business capabilities, bounded contexts, data ownership, and runtime behavior.
Recognize distributed monolith, shared database, synchronous chain, and nano-service anti-patterns.
Explain why database ownership and event-driven collaboration matter in microservice systems.

Major section

Begin With One Service Promise · Start With the Service That Owns a Promise

Telemetry means records sent from a system so its state can be watched.

The first choice is not how many services to draw.
A separate service can isolate change and scale, but it adds calls, state, release work, and on-call duty.
A device reports high heat.

Major section

In 60 Seconds · Minimum Viable Understanding

A service boundary is an ownership boundary.: A service is useful only when a team can build, run, change, and support it without constant coordination.

SOA is usually about integrating capabilities through stable service contracts across an enterprise.
Microservices are about independently deployable services that can be owned, changed, scaled, and observed by focused teams.
SOA is integration-first.: It is valuable when existing systems, protocols, and contracts must interoperate without rewriting everything.

Major section

Boundaries Come Before Services · Test a Service Boundary

The first design question is not whether to use microservices.

A service boundary is useful only when it protects a capability that has its own vocabulary, data, owner, runtime needs, and failure behavior.
If the team cannot name those things, a new service mostly adds network calls and coordination.

Major section

Distributed Costs You Must Pay

Calls can be slow, duplicated, reordered, partially applied, or unavailable.

Data can become eventually consistent.
Contract changes can break old devices, field gateways, mobile apps, dashboards, or partner integrations that stay online for years.
The service boundary therefore needs contracts, versioning, failure rules, and observability before it becomes production-critical.

Major section

Distributed Costs You Must Pay (continued)

This arrangement explains the distributed cost in operational terms: ingestion can keep accepting data when notification slows, but every API and event edge now needs versioning, retry, idempotency, and observability.

Idempotency keeps repeated commands, alerts, or webhook deliveries from causing duplicate side effects.
Event design separates facts that happened from commands that ask another service to act.
Backpressure protects ingest and alerting when telemetry spikes or downstream services slow down.

Major section

Distributed Costs You Must Pay (continued)

Failure semantics must be part of the boundary.

Point to it: the flow diagram — telemetry.received events, an owned write model, contracts that are versioned, observed, tested.
Data ownership is the part teams most often underbuild.
If a notification provider is down, telemetry should still be accepted and alerts should enter a retryable state.

Major section

Distributed Costs You Must Pay (continued)

A telemetry service can publish events and expose read APIs, but other services should not depend on its private table names, partitioning scheme, retention jobs, or compression choices.

A command service can emit command-state events, but it should not let alerting update command rows to force a workflow forward.
A registry can expose device identity, certificate state, and ownership, but it should protect certificate rotation and provisioning internals from consumers.
If the registry API is unavailable, ingestion may reject unknown devices, use a bounded identity cache, or mark messages for quarantine depending on the product risk.

Major section

Most Valuable Understanding · Architecture Choice Map

Microservices are not a badge of maturity.

Without those, a modular monolith is often the more professional design.
The question is not "monolith or microservices?" The better question is "which architecture matches the current evidence?".

SOA architecture choice map for IoT platforms

Major section

SOA and Microservices · Service Boundary Review

SOA and microservices overlap, but their center of gravity is different.

Centralized governance where consistency is important.
This returns to the chapter's narrative: distribution is justified by an independently governable capability, not by making more network calls.
The capability has its own vocabulary and rules.
A team can own the full lifecycle.

Service boundary review for an IoT platform

Major section

Data Ownership and Collaboration · Communication Patterns

Microservices become real only when data ownership is clear.

A service can publish facts and expose APIs, but other services should not depend on its internal tables.
Other services use APIs, events, or replicated read models.
Schema changes are hidden behind contracts.
Cross-service workflows use events, sagas, or explicit orchestration.

Major section

Common Patterns · Resilience Readiness Check

These patterns are useful when they solve a concrete IoT pressure.

Authentication, throttling, protocol translation, and observability can be shared at the edge; domain authorization and owned data remain behind explicit service contracts.
This keeps the pattern connected to the running boundary argument rather than turning the gateway into a hidden monolith.

API gateway architecture for IoT services

Major section

Summary · Key Takeaway

Otherwise, strengthen the module boundary and keep learning.

SOA is strongest for stable service integration across existing systems.
Microservices are strongest when teams need independent ownership, deployment, data control, and runtime scaling.
A modular monolith is a valid starting architecture when the domain is still being learned.

Deck summary

Key takeaways

Telemetry means records sent from a system so its state can be watched.

A service boundary is an ownership boundary.: A service is useful only when a team can build, run, change, and support it without constant coordination.
The first design question is not whether to use microservices.
Calls can be slow, duplicated, reordered, partially applied, or unavailable.
This arrangement explains the distributed cost in operational terms: ingestion can keep accepting data when notification slows, but every API and event edge now needs versioning, retry, idempotency, and observability.

Retrieval practice

Recall check 1 of 5

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

Q1A small IoT product team is still learning its device lifecycle, telemetry, alert, and dashboard requirements. The team can release one application quickly and does not yet have separate teams for each capability. What is the best starting architecture?

AA modular monolith with explicit internal domain boundaries

BDozens of microservices so the team never has to refactor

COne shared database with every team reading every table

DA service mesh before any service boundaries are known

Show answer

Answer: A Start with the simplest architecture that lets the team learn quickly without hiding domain boundaries.

Retrieval practice

Recall check 2 of 5

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

Q2A manufacturer must connect ERP, MES, SCADA, warehouse systems, and multiple IoT platforms. The goal is reliable integration across existing systems, not replacing them with a new cloud product. Which style is the better fit?

ASOA-style integration with stable contracts and mediation where needed

BA new microservice for every database table in the enterprise

CPoint-to-point integrations between every pair of systems

DA single monolith that replaces all systems immediately

Show answer

Answer: A SOA is useful when the architecture problem is enterprise integration across existing capabilities.

Retrieval practice

Recall check 3 of 5

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

Q3An IoT platform splits device registry, telemetry, and alerting into separate services, but all three services directly read and write the same PostgreSQL tables. A registry schema change breaks alerting. What is the core anti-pattern?

AShared database coupling

BToo much asynchronous messaging

CToo much observability

DToo many device protocols

Show answer

Answer: A Database-per-service does not mean no data sharing.

Q4Place each SOA responsibility where it lives so you can trace a request without confusing the provider, mediation layer, and consumer.

AService provider

BService contract

CService registry

DEnterprise service bus

EService consumer

Show answer

Answer: A Separate published capability, discovery and mediation, and requested outcome so you can review coupling and failures at the correct service boundary.

Retrieval practice

Recall check 4 of 5

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

Q5Complete the service boundary rationale for extracting telemetry ingestion from a modular IoT platform:

Acapability: receive_validate_and_publish_telemetry

Bcapability: all_database_queries

Ccapability: every_user_interface_screen

Dcapability: shared_utility_functions

Show answer

Answer: A A useful extraction record names the business capability, protects data ownership, collaborates through contracts or events, and documents a concrete operating reason for the split.

Retrieval practice

Recall check 5 of 5

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

Q6An IoT platform has device registry, telemetry ingestion, and notifications in one modular application. Telemetry volume has a very different runtime profile from the rest of the app, and one team can own telemetry end to end. What is the strongest reason to extract telemetry as a service?

AEvery module needs a separate deployment before launch

BTelemetry has distinct load, ownership, and failure limits

CExtraction removes the need for APIs and event contracts

DDatabase sharing becomes safer once telemetry is remote

Show answer

Answer: B Extraction is justified by evidence: ownership, runtime profile, data boundary, failure isolation, and independent deployment.

Print reference

Answers 1 of 2

Answer key.

A · Start with the simplest architecture that lets the team learn quickly without hiding domain boundaries.
A · SOA is useful when the architecture problem is enterprise integration across existing capabilities.
A · Database-per-service does not mean no data sharing.
A · Separate published capability, discovery and mediation, and requested outcome so you can review coupling and failures at the correct service boundary.

Print reference

Answers 2 of 2

Answer key.

A · A useful extraction record names the business capability, protects data ownership, collaborates through contracts or events, and documents a concrete operating reason for the split.
B · Extraction is justified by evidence: ownership, runtime profile, data boundary, failure isolation, and independent deployment.