Event-Driven Architecture — Don't Publish Your Internals

Visual summary of the video: data-distribution events vs. explicit business events.

1. The Trap: CRUD events = data replication BAD

You think you decoupled. You just copied your DB to every consumer.

Shipment Servicestatus=4, weight, address(internal DB) Brokerpub/sub Notification Svccached copy Analytics Svccached copy Billing Svccached copy shipment.status_changedaddress_updated 3 consumers × same rows = replication
publishshipment status changed = CRUD / state-change event

Consumers infer internals: "status 4 = delivered". Change the meaning → break every consumer. No different than calling another service's DB directly.

2. The Fix: explicit business events GOOD

Model events around what actually happened, not state.

Shipment Servicebusiness behavior Broker Notificationsreact → send email Logisticsreact → update tracking Billingreact → charge on delivery shipment_deliveredshipment_delayeddelivery_attempted consumers react to meaning — no reverse engineering
explicit event❌ status_changed✅ shipment_delivered

Domain vs Integration Events (inside vs outside)

One boundary. Internal = change freely. External = versioned contract.

SERVICE BOUNDARY Domain / Inside eventsfine-grained · internal ·freely mutate & evolve I'm internal, I can change it Translateto public contract Integration / Outsidecoarser · summary checkpointversioned · backwards-compatibletreated like a public API make it a contract change without versioning → break consumers
inside = domain, private, granularoutside = integration, public, versioned

CDC & Reporting: don't leak internals

Distributing data is OK for reporting — but translate raw CDC to a public summary event first.

DB / CDC toolraw row changes Brokerpub/sub Reportinglocal copy ↯ leaks internals, masked DB replicationBAD DB / CDC toolraw row changes Translate→ summary event Brokersummary events Reporting datafrom summary events translate raw CDC → contract first, then publish
BAD: publish raw CDCGOOD: translate CDC → summary event → publish

The Design Question

"What can subscribers actually need this for?"

✅ "React & do something when it happens"
Send email on delivery → shipment_delivered. Explicit, meaningful. This is correct EDA.
⚠ "I want a local cache copy here"
Design smell. Ask: why does that data live there? Are service boundaries misaligned?
Diagrams summarize the video: event-driven architecture ≠ decoupled when you publish CRUD/state-change events. Be explicit about what happened.