Integration Starts With Contracts and Coupling
Goal
Open the chapter by describing integration through contracts, time, ownership, and failure.
The Short Version
An integration choice defines what is communicated, when participants must be available, and how failure crosses ownership boundaries.
Contracts include payload meaning, schema, versioning, identity, authorization, timing, delivery, and error semantics. The important architecture move is to make the boundary explicit before selecting a cloud feature. A feature can automate a decision, but it cannot decide the organization's risk tolerance, ownership model, or acceptable failure behavior.
Use this section as a decision tool. Name the actor or producer, the protected or affected resource, the contract between them, the conditions under which the action is allowed, and the evidence that will show whether the design worked.
Mental Model
Use a coupling map across time, availability, deployment, data model, ownership, and failure propagation.
flowchart LR
N1["Producer intent"] --> N2["Contract"] --> N3["Delivery mechanism"] --> N4["Consumer"] --> N5["Outcome"] --> N6["Failure evidence"]Read the diagram from left to right, then review it from right to left. The forward pass explains how work succeeds. The reverse pass asks whether an operator can trace an outcome back to its initiating identity, input, policy, route, or contract.
Architecture Decisions
| Decision dimension | Question to make explicit |
|---|---|
| Intent | Is this a query, command, notification, fact, stream, or process step? |
| Coupling | Must the producer wait for a named consumer? |
| Delivery | What can be duplicated, delayed, reordered, or lost? |
| State | Where is process progress, correlation, and replay position stored? |
| Change | How do contracts evolve without forcing coordinated releases? |
The answers should be recorded with the workload design. If the answer is merely "the platform default," the team has discovered an assumption, not completed an architecture decision.
Core Ideas
Contracts include payload meaning, schema, versioning, identity, authorization, timing, delivery, and error semantics
Contracts include payload meaning, schema, versioning, identity, authorization, timing, delivery, and error semantics. Make the owner, boundary, failure behavior, and evidence explicit. That turns the concept from a configuration choice into a design decision that another team can review and operate.
Synchronous interaction creates temporal coupling; asynchronous interaction introduces queues, lag, duplicate, and eventual-consistency concerns
Synchronous interaction creates temporal coupling; asynchronous interaction introduces queues, lag, duplicate, and eventual-consistency concerns. Make the owner, boundary, failure behavior, and evidence explicit. That turns the concept from a configuration choice into a design decision that another team can review and operate.
Deployment, data, and ownership coupling can remain even when communication is asynchronous
Deployment, data, and ownership coupling can remain even when communication is asynchronous. Make the owner, boundary, failure behavior, and evidence explicit. That turns the concept from a configuration choice into a design decision that another team can review and operate.
Provider Lenses
AWS provides API Gateway, SQS, SNS, EventBridge, Kinesis, and Step Functions among its implementation choices. Azure provides API Management, Service Bus, Event Grid, Event Hubs, Logic Apps, and Durable Functions. Choose first among request-response, work queue, publish-subscribe, event routing, durable stream, and workflow semantics; then map those semantics to a provider service.
Provider lenses are useful for implementation planning, but they should come after the provider-neutral decision. This keeps the reasoning portable and makes differences in defaults, scope, and operational responsibility easier to detect.
Example: Applying the Decision
Compare a checkout call that requests an immediate price with a notification that an order was accepted for later fulfillment.
Keep checkout validation synchronous, submit accepted orders durably, orchestrate payment and inventory when the business needs visible process state, publish outcome events for fulfillment and notifications, and make every state-changing consumer idempotent.
A review should finish with named owners, a testable success path, expected failure modes, and observable evidence. That is more useful than a diagram that only proves the components can connect.
Common Mistakes
Choosing an integration service before defining the business contract. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.
Calling a design decoupled merely because it uses messages. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.
Ignoring who changes and supports a shared schema. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.
If Someone Asks You
What should be decided before choosing an API or messaging service?
A clear answer is:
An integration choice defines what is communicated, when participants must be available, and how failure crosses ownership boundaries.
I would then show the decision path, the responsibility boundary, and the evidence used to review it. That explanation connects the technical mechanism to its architecture purpose.
What You Should Remember
An integration choice defines what is communicated, when participants must be available, and how failure crosses ownership boundaries.
Questions to Check Your Understanding
Which elements belong in an integration contract?
What coupling does asynchronous communication remove and add?
Why can ownership coupling survive a broker?
Further Study
Azure Architecture Center: Event-driven architecture style - Use this authoritative source to deepen the section's provider-neutral control and decision model.