--- title: Event Driven Architecture and Coupling: You’re Not as... description: Publishing events doesn't automatically mean services are decoupled; broadcasting CRUD-style state-change events like ShipmentStatusChanged just replicates... canonical: https://daily.dev/posts/event-driven-architecture-and-coupling-you-re-not-as-decoupled-as-you-think-qsutamgqk twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Event Driven Architecture and Coupling: You’re Not as Decoupled as You Think | daily.dev og:description: Publishing events doesn't automatically mean services are decoupled; broadcasting CRUD-style state-change events like ShipmentStatusChanged just replicates... og:url: https://daily.dev/posts/event-driven-architecture-and-coupling-you-re-not-as-decoupled-as-you-think-qsutamgqk og:image: https://api.daily.dev/og/posts/QSUtaMGqK.png og:image:alt: Event Driven Architecture and Coupling: You’re Not as Decoupled as You Think og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Event Driven Architecture and Coupling: You’re Not as Decoupled as You Think **[CodeOpinion](https://daily.dev/sources/codeopinion)** · [@codeopinion](https://daily.dev/codeopinion) · 11 min read · 0 upvotes · 0 comments ## Summary Publishing events doesn't automatically mean services are decoupled; broadcasting CRUD-style state-change events like ShipmentStatusChanged just replicates internal data models across services, creating hidden semantic coupling. The piece argues for explicit, behavior-centric events (e.g. ShipmentDispatched, ShipmentDelivered) that describe what actually happened rather than raw state transitions. It distinguishes domain events (internal, mutable) from integration events (public contracts requiring versioning), warns against using change data capture to leak database internals, and suggests asking what a consumer actually needs an event for as a design heuristic. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is the difference between domain events and integration events? Domain events are internal and private to a service boundary, meaning the owning team can freely mutate or change them since nothing outside depends on them. Integration events are public contracts consumed by other services, so they require versioning and backward compatibility, similar to how a public HTTP API must be managed once external consumers rely on it. _Architects weighing event contract design can find deeper breakdowns of these patterns on daily.dev._ ### Why does publishing a ShipmentStatusChanged event create coupling even without synchronous calls? Because consumers must infer meaning from internal state values (like a status code of 4 meaning 'delivered'), they end up implicitly understanding another service's data model, which is a hidden form of coupling through message semantics. Removing a synchronous HTTP call only eliminates temporal coupling, not this semantic coupling, so changing what a status value means later breaks every subscriber. _Developers debugging brittle event-driven systems often track these architecture pitfalls on daily.dev._ ### How should change data capture (CDC) be used safely in event-driven systems without leaking internals? CDC should feed a translation layer that converts raw internal database changes into explicit, summary-level integration events with a defined public contract, rather than publishing raw data model changes directly to consumers. This avoids exposing database internals while still enabling use cases like building a reporting data source from multiple services. _Teams evaluating CDC pipelines can keep up with data architecture patterns like this via daily.dev._ ## Similar posts on daily.dev - [\*\*Data-Driven vs Event-Driven Architecture: How to Pick the Right One\*\*](https://daily.dev/posts/data-driven-vs-event-driven-architecture-how-to-pick-the-right-one--hhq5msjoy) · SitePoint · 113 upvotes · 5 comments - [Patterns & Best Practices in Event-Driven Systems — Kogan.com Dev Blog](https://daily.dev/posts/patterns-best-practices-in-event-driven-systems-kogan-com-dev-blog-klr34bwfw) · Kogan.com · 44 upvotes · 2 comments - [Understanding Event Driven Headless Commerce in Depth](https://daily.dev/posts/understanding-event-driven-headless-commerce-in-depth-okfpmelpy) · Netguru · 0 upvotes · 0 comments - [We mistook event handling for architecture](https://daily.dev/posts/we-mistook-event-handling-for-architecture-ox5jylwip) · InfoWorld · 0 upvotes · 0 comments --- Tags: [#career](https://daily.dev/tags/career), [#architecture](https://daily.dev/tags/architecture), [#microservices](https://daily.dev/tags/microservices), [#domain-driven-design](https://daily.dev/tags/domain-driven-design) [View this post on daily.dev](https://daily.dev/posts/event-driven-architecture-and-coupling-you-re-not-as-decoupled-as-you-think-qsutamgqk) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Event Driven Architecture and Coupling: You’re Not as Decoupled as You Think","url":"https://daily.dev/posts/event-driven-architecture-and-coupling-you-re-not-as-decoupled-as-you-think-qsutamgqk","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/event-driven-architecture-and-coupling-you-re-not-as-decoupled-as-you-think-qsutamgqk"},"datePublished":"2026-10-04T13:07:22.116Z","dateModified":"2026-10-05T10:00:17.800Z","description":"Publishing events doesn't automatically mean services are decoupled; broadcasting CRUD-style state-change events like ShipmentStatusChanged just replicates...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/810d2f4c1f0e23b9e79219679979959e?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/810d2f4c1f0e23b9e79219679979959e?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"CodeOpinion","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Person","name":"Derek Comartin","url":"https://daily.dev/codeopinion","image":"https://lh3.googleusercontent.com/a-/AOh14GgoQapb7NmLN1TZ6L-UCxkRpDZ4H7LKwud1DUZCTSI=s100","interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"EndorseAction"},"userInteractionCount":800}},"commentCount":0,"discussionUrl":"https://daily.dev/posts/event-driven-architecture-and-coupling-you-re-not-as-decoupled-as-you-think-qsutamgqk","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"career,architecture,microservices,domain-driven-design","timeRequired":"PT11M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"CodeOpinion","item":"https://daily.dev/sources/codeopinion"},{"@type":"ListItem","position":3,"name":"Event Driven Architecture and Coupling: You’re Not as Decoupled as You Think"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/event-driven-architecture-and-coupling-you-re-not-as-decoupled-as-you-think-qsutamgqk#faq","mainEntity":[{"@type":"Question","name":"What is the difference between domain events and integration events?","acceptedAnswer":{"@type":"Answer","text":"Domain events are internal and private to a service boundary, meaning the owning team can freely mutate or change them since nothing outside depends on them. Integration events are public contracts consumed by other services, so they require versioning and backward compatibility, similar to how a public HTTP API must be managed once external consumers rely on it. Architects weighing event contract design can find deeper breakdowns of these patterns on daily.dev."}},{"@type":"Question","name":"Why does publishing a ShipmentStatusChanged event create coupling even without synchronous calls?","acceptedAnswer":{"@type":"Answer","text":"Because consumers must infer meaning from internal state values (like a status code of 4 meaning 'delivered'), they end up implicitly understanding another service's data model, which is a hidden form of coupling through message semantics. Removing a synchronous HTTP call only eliminates temporal coupling, not this semantic coupling, so changing what a status value means later breaks every subscriber. Developers debugging brittle event-driven systems often track these architecture pitfalls on daily.dev."}},{"@type":"Question","name":"How should change data capture (CDC) be used safely in event-driven systems without leaking internals?","acceptedAnswer":{"@type":"Answer","text":"CDC should feed a translation layer that converts raw internal database changes into explicit, summary-level integration events with a defined public contract, rather than publishing raw data model changes directly to consumers. This avoids exposing database internals while still enabling use cases like building a reporting data source from multiple services. Teams evaluating CDC pipelines can keep up with data architecture patterns like this via daily.dev."}}]} ```