--- name: eda-coupling-diagnosis description: Invoke when someone claims "we use EDA so we're loosely coupled", when evaluating an event bus or message broker, adding a consumer to an event stream, or when an event schema change ripples to many consumers. Diagnoses the coupling event-driven architecture hides. --- # EDA Coupling Diagnosis ## EDA Coupling Diagnosis **Source:** Enterprise Integration Patterns, Gregor Hohpe & Bobby Woolf (2003) + Addendum 2: "Event-Driven = Loosely Coupled? Not so fast!" (Gregor Hohpe, ~2022) — Coupling Comparison Table; "Inversion of (Coupling) Control" section ______________________________________________________________________ ### R — Reading (Original Source) > "Event-Driven Architectures are loosely coupled, but very similar to any asynchronous, message-oriented interactions. Most of the decoupling properties of EDAs derive from the use of Publish-Subscribe Channels, not event semantics... If you don't have control over the source, Publish-Subscribe channels are ideal. In your own application (where you have control over sender and receiver), adding recipients free of side effects is a less-pronounced benefit." > > "A Recipient List, which also sends messages to multiple recipients, requires a change to the source to add a recipient. This makes the source subject to change propagation... Using an event broker like EventBridge negates some of the 'right-to-left' decoupling benefits of Publish-Subscribe channels. You won't have to modify the sender, but you have to modify a central element nonetheless." ______________________________________________________________________ ### I — Interpretation The claim "event-driven architectures are loosely coupled" is mostly marketing language that collapses a multi-dimensional analysis into a single reassuring adjective. When you compare three interaction styles — synchronous RPC, asynchronous point-to-point messaging, and Publish-Subscribe — across the eight coupling dimensions, a clear picture emerges: the large step in decoupling happens between RPC and async messaging, not between async messaging and Pub-Sub. Temporal coupling (does the sender block waiting for the receiver?), location coupling (does the sender hardcode the receiver's address?), and space coupling (can an intermediary be inserted transparently?) all improve dramatically the moment you switch from synchronous RPC to asynchronous messaging. Pub-Sub and point-to-point async messaging are nearly identical on these dimensions. The ONE dimension where Pub-Sub uniquely outperforms point-to-point messaging is topology coupling: adding a new recipient to a Pub-Sub channel requires no change to the sender or existing subscribers. This is the genuine, exclusive benefit of the Pub-Sub model. But data format coupling and semantic coupling are tight in all three styles — naming a message "OrderPlaced" instead of "ProcessOrder" changes nothing about whether sender and receiver must agree on field names, types, and semantics. There is also a directional subtlety: Pub-Sub's topology decoupling is asymmetric. It decouples adding subscribers from the sender (right-to-left), but the sender's schema changes still propagate to all subscribers (left-to-right coupling remains). This asymmetry matters for two reasons. First, it explains why the benefit is most valuable when you don't control the source — if you add a subscriber to an AWS service event stream, the AWS team doesn't know you exist and will never be asked to change their service. Second, it explains the growth trap: as more subscribers accumulate, the event schema becomes harder to evolve because each subscriber is a new dependency on the format. The decoupling that made it easy to grow the system makes it hard to change the system later. Finally, the AWS EventBridge trap: EventBridge rules and SNS fanout patterns look like Pub-Sub from the outside but function as Recipient Lists internally. Adding a recipient requires modifying the rule (a central element), reintroducing right-to-left coupling even though the original event producer is untouched. The coupling is displaced from the sender to the broker configuration, but it still exists. The diagnostic question is always: which specific coupling dimension does your architecture actually reduce, and at what cost to the other dimensions? ______________________________________________________________________ ### A1 — Past Application (Author's Cases) **Hohpe's coupling comparison table** (Addendum 2): Comparing RPC, P2P async messaging, and Pub-Sub across temporal, location, space/topology, data format, and semantic coupling dimensions shows that P2P messaging and Pub-Sub share the same values on five of the eight dimensions. Only topology coupling differs. **AWS EventBridge as Recipient List** (c09): Hohpe analyzed EventBridge's rule and target system and concluded it behaves as a Recipient List, not a Pub-Sub channel. Adding a new event target requires modifying an EventBridge rule — a centralized element. The producer (which may be an AWS service) is untouched, but the integration configuration must change. The right-to-left decoupling benefit is negated. **The Pub-Sub growth trap** (x11): Teams that freely add subscribers over time because "there's no coupling cost" eventually discover that changing an event schema requires coordinating every subscriber simultaneously. The ease of adding recipients during growth becomes a coordination burden at modification time. **Bond Trading Pub-Sub vs. P2P selection** (c04): The bond trading system correctly chose Pub-Sub for server-to-client flows (pricing data published to multiple trader workstations) and Point-to-Point for client-to-server (each trade command destined for exactly one handler). The decoupling benefit of Pub-Sub was real precisely because the server could not know which workstations were listening at any given moment. ______________________________________________________________________ ### A2 — Future Trigger ★ Invoke this skill when you encounter any of the following: - **"We're using EDA so we're loosely coupled"** — this claim requires interrogation. Ask: loosely coupled on which dimension specifically? - **Evaluating a new event bus or message broker** — before adoption, determine which coupling dimensions it actually reduces and which it leaves unchanged - **Adding a new consumer to an existing event stream** — check whether the channel is true Pub-Sub or a Recipient List under the hood; the former is free, the latter requires a config change - **An event schema change ripples to many consumers** — this is the Pub-Sub growth trap manifesting; diagnosis should start with counting topology-decoupled subscribers who are data-format-coupled - **"We renamed the event from X to Y and now 12 services are broken"** — semantic and data-format coupling survive the adoption of EDA; this is expected behavior, not a bug in the event bus - **Evaluating AWS EventBridge, SNS fanout, or similar managed event routers** — determine whether the routing mechanism is true Pub-Sub or a managed Recipient List before claiming topology decoupling - **Deciding whether to use events vs. commands in a messaging design** — event semantics (naming) change nothing about coupling dimensions; the channel type is what matters - **Greenfield microservice architecture using "event-driven" as a selling point** — challenge the architect to specify which coupling dimensions the EDA design actually reduces ______________________________________________________________________ ### E — Execution (Steps) 1. **Name the interaction style under discussion.** Is the system using synchronous RPC, asynchronous point-to-point messaging, or Publish-Subscribe channels? If "events" are involved, determine which channel type carries them — a P2P channel with an event-shaped message is not Pub-Sub. 2. **Run the coupling comparison.** For the specific integration point, evaluate temporal, location, topology, data format, and semantic coupling across the actual architecture. Ask: which dimensions change compared to RPC? Which change compared to P2P messaging? 3. **Identify the unique Pub-Sub benefit.** If topology decoupling (adding recipients without sender change) is the claimed benefit, verify the channel is true Pub-Sub, not a Recipient List. Check whether adding a new consumer requires any central change (broker config, routing rule, subscription list). If yes, the benefit is reduced. 4. **Check coupling direction.** Confirm whether the source is under your control. If you control both sender and receiver, Pub-Sub's topology benefit is weaker — you can change the sender when needed. If you don't control the source (cloud platform events, partner systems, third-party integrations), Pub-Sub's right-to-left decoupling is its most valuable property. 5. **Audit data format and semantic coupling separately.** Regardless of channel type, all interaction styles share these coupling dimensions. Identify which fields consumers depend on, whether the event schema has a governance process, and how many consumers would need to change if a field were renamed or removed. This is where the growth trap lives. 6. **Decide based on dimensions, not style labels.** Use Pub-Sub when the topology decoupling benefit is real and the source is uncontrolled. Use P2P messaging when the destination is singular and the coupling cost of Pub-Sub's schema dependency is not offset by the topology benefit. Do not use EDA as a synonym for "decoupled." ______________________________________________________________________ ### B — Boundary (When Not to Apply) **The analysis is limited to three styles.** Hohpe's comparison covers RPC, P2P async messaging, and Pub-Sub. It does not extend to streaming patterns (Kafka log compaction, event sourcing, CQRS), choreography vs. orchestration, or service mesh interceptors. These require their own coupling analysis. **The framework does not prescribe acceptable coupling levels.** It diagnoses which dimensions are coupled but does not tell you which level of coupling is acceptable for your system. That depends on your team's control over endpoints, the rate of change in your domain, and your organization's tolerance for coordination overhead — factors the framework makes explicit but does not resolve. **Topology decoupling's value depends on team structure.** If a single team owns both sender and receiver, topology coupling is nearly free to manage — rename it, and change both. If separate teams or organizations own sender and receiver, the same coupling is expensive. Conway's Law means the value of Pub-Sub's topology decoupling scales with organizational boundary count, not just component count. **The growth trap is real but not universal.** Systems where the event schema is stable, well-versioned, or consumed by a small, controlled subscriber set do not fall into the growth trap. The risk is proportional to the number of independent subscribers and the rate of schema evolution. **Hohpe's addenda pre-date widespread adoption of AsyncAPI, schema registries, and event catalogs.** These tooling advances partially mitigate the "hidden subscriber" problem by making subscription counts and schema dependencies observable. The analytical framework remains valid; the severity of the growth trap is reduced when schema governance tooling is in place. ______________________________________________________________________ ## Related Skills - composes-with: `multidimensional-coupling-assessment` — EDA coupling diagnosis is a specialization of the full 8-dimension coupling assessment, applied to the specific question of whether event-driven architectures deliver on their decoupling claims. - depends-on: `integration-style-selection` — Integration style selection provides the foundational vocabulary (Messaging vs. RPC vs. File Transfer); EDA coupling diagnosis refines the analysis when Messaging/Pub-Sub is the chosen style. - **canonical-data-model-decision** — *enables* → Diagnosing tight data-format coupling across many Pub-Sub subscribers is the precise problem that a Canonical Data Model solves; the diagnosis should precede the CDM investment decision. - **Competing Consumers vs. Dispatcher** — *contrasts-with* → EDA coupling diagnosis addresses whether to use Pub-Sub at all and what coupling it introduces; competing consumers addresses how to parallelize within a messaging topology that has already been chosen. ______________________________________________________________________ ## Provenance - **Source:** Enterprise Integration Patterns, Gregor Hohpe & Bobby Woolf (2003) + Addendum 2 (Gregor Hohpe, ~2022)