CONCEPT Cited by 1 source
Notification-of-change event¶
Definition¶
A notification-of-change event is an event whose payload contains only the fact that something changed — typically an entity identifier and an event type — but not the new state. Consumers receiving such an event are expected to call back to the source system to fetch the authoritative current state.
"The event stream becomes a notification of change rather than a log of changes." — sources/2026-05-04-netflix-democratizing-machine-learning-building-the-model-lifecycle-graph
Canonical example: Netflix MDS¶
Source systems emit events of the form:
The consumer (MDS) calls
GET /api/v1/instances/ranking-model-v5-20XX0101 to fetch the
full descriptor. The event itself is a trigger, not data.
The structural property: order independence¶
The defining consequence of using thin notification-of-change events:
"This design has a crucial property: the order of events doesn't matter. MDS always fetches the latest facts from the source of truth. This pattern decouples the event stream from state consistency. If the event bus drops a message or delivers it out of order, the next event corrects the state." — sources/2026-05-04-netflix-democratizing-machine-learning-building-the-model-lifecycle-graph
Because the event payload is content-free (only an identifier), re-processing an old event still results in fetching the current state, not stale state. This makes the consumer:
- Robust to dropped messages — the next event for the same entity will catch up the state.
- Robust to out-of-order delivery — last write wins by construction; whichever event runs last sees the latest source.
- Idempotent at the consumer — replaying an event has no effect on state.
Tradeoff: read amplification on source systems¶
Every event triggers a callback to the source API. At scale:
"The tradeoff is that we place additional read load on source systems during hydration and need to be deliberate about rate limiting, caching, and backoff in our enrichment workers so that we don't overload them." — sources/2026-05-04-netflix-democratizing-machine-learning-building-the-model-lifecycle-graph
The pattern moves complexity from producers (no need to serialize full state) to consumers (need to absorb hydration load + implement rate-limiting). Producers stay simple; consumers become the integration point.
Distinct from event sourcing¶
| Aspect | Event sourcing | Notification of change |
|---|---|---|
| Event payload | The full state delta (or new state) | Just an identifier + event type |
| Source of truth | The event log itself | An external system the events point at |
| Replay semantics | Reconstruct state by replaying all events | Fetch current state from source on demand |
| Order sensitivity | Strict ordering required | Order doesn't matter |
| Consumer storage | Materialized view of replayed state | Cached snapshot of source-of-truth state |
In event sourcing, the event log is the system of record. In notification-of-change, the event log is a trigger mechanism and the source-of-truth API is the system of record.
Distinct from change-data-capture¶
| Aspect | CDC | Notification of change |
|---|---|---|
| Event payload | The actual changed row(s) — before + after | Just an identifier |
| Tap point | Database transaction log | Application-emitted explicit event |
| Coverage | Every row change | Only changes the application chose to announce |
| Consumer reads source DB? | Usually no — payload has the data | Yes — payload has only a pointer |
CDC carries the data; notification-of-change carries only a pointer. CDC is heavier on the wire but lighter on consumer-source coupling; notification-of-change is lighter on the wire but heavier on consumer-source coupling.
See also concepts/change-data-capture for the dual approach.
When to use it¶
- The source system has a well-defined query API and can absorb read load.
- Producers are diverse / changing / can't be expected to know every consumer's schema needs.
- The event bus may drop / reorder messages, and you want correctness despite that.
- The change-volume is moderate (high enough to need events; not so high that source-API hydration becomes a bottleneck).
When not to use it¶
- The source system can't tolerate the read amplification.
- You need exact change-deltas (you care about what changed, not just something changed — e.g. for audit trails or financial reconciliation).
- The consumer needs to react in milliseconds — hydration adds latency that CDC payloads don't.
Seen in¶
- sources/2026-05-04-netflix-democratizing-machine-learning-building-the-model-lifecycle-graph — Netflix MDS uses thin notification-of-change events from six source systems via Kafka + SNS/SQS.