Event Notification vs State Transfer

Event-driven systems use several event styles. Your choice shapes coupling, payload size, and how often consumers must call back to the producer.

Event notification sends a thin message that something happened — usually just an ID. Consumers call back for the details only if they actually need them.

Thin notifications are small and decoupled in data, but consumers must query the source — adding load and runtime coupling. Tiny payloads, extra callbacks.

Event-carried state transfer packs the data consumers need right into the event, so they can act without ever calling back.

Carrying state kills callbacks and boosts availability, but payloads grow and data can go stale if you don't version carefully. Independence vs. duplication.

Event sourcing stores the full sequence of events as the source of truth. You derive current state by replaying them — no separate stored state.

Event sourcing gives you a complete audit history plus the power to rebuild state or derive new views anytime — at the cost of added complexity.

Match style to need: notification when details are rarely needed, state transfer when consumers must act alone, sourcing when history and replay are core.

Coupling shifts with style: notification couples consumers to the producer at runtime; state transfer couples them to the schema. Version both thoughtfully.

Real systems mix styles: a coarse notification triggers a lookup, while frequently needed data travels as state to avoid chatty callbacks.

A solid default: carry the state consumers commonly need, keep events versioned, and save event sourcing for domains where full history is genuinely valuable.

Pick the right style.

Three event styles: notification (thin, callback-driven), state transfer (data travels for autonomy), and sourcing (events are truth, state replayed). Real systems blend them.