Pattern · seen in 1 breakdown across 1 company

Content-Free Change Events

Definition

When replicating or synchronizing data from a source of truth into a derived store, emit events that carry only the identity of what changed — never the changed content. Consumers react by reading the entity's current state from the source of truth and writing the derived store idempotently. Because every apply fetches fresh truth, the event stream needs none of the properties that make change streams hard: events can be arbitrarily reordered, duplicated, retried, delayed, paused, or throttled with zero correctness consequence, and no ordered log, sequence numbering, or binlog parsing has to exist. The queue becomes pure signaling; all authority stays in the source.

The price is read amplification against the source of truth — each event costs a fresh read of current state, often against the very system being relieved — and freshness that is eventual without ordering guarantees: a derived store converges to truth but transiently skips intermediate states (which is usually the point, not a bug). The pattern composes naturally with priority tiers (change events above access events) to spend the staleness budget where it is cheapest. Boundary against ordered-log replication (CDC/binlog streaming): that approach carries state in-stream and demands ordering, exactly-once-ish delivery, and parser maintenance in exchange for not re-reading the source; choose by whether the source can afford the reads and whether intermediate states matter. Boundary against Designated Source of Truth: that pattern names which system wins and how recovery reconciles; this one is a transport discipline for keeping derived stores following the winner cheaply.

When it applies

01Live migrations and derived-store synchronization where the source of truth remains queryable and intermediate states don't need to be preserved
02Pipelines that must be pausable, throttleable, and safely retryable mid-flight — operational control matters more than event-stream fidelity
03Teams that want replication without building or operating CDC infrastructure (binlog parsers, ordered logs, exactly-once plumbing)

Tradeoffs

Read amplification on the source of truth — every event costs a state fetch, often against the strained system the migration exists to relieve
No intermediate states: the derived store sees only current truth at apply time, so audit trails and event-sourced consumers need a different mechanism
Convergence depends on an event firing for every change — a missed enqueue is a silent permanent divergence, which is why the pattern pairs with a full background scan as the completeness backstop

The same move, 1 ways

Every row is a production system that bet on this pattern — the note says how, in that system's own terms.

Canva
Canva Engineering Blog
2022
This is the migration's quiet masterpiece: queue messages that record only that a media was created, updated, or read, never the content, with workers re-reading the current state from the MySQL primary and writing DynamoDB. Because the state always comes fresh from the source of truth, reordering, retries, pauses, and throttling are all safe, and the ordered-log alternative (with its hand-written log parser) never has to exist. The post is explicit about the options it rejected: writing to both stores, replaying an ordered log, and AWS's migration service. Read the breakdown →

Problems this pattern answers

The walls where its breakdowns live — each opens the cross-company comparison.