Event-Carried State Transfer
Event-carried state transfer includes full entity state in each event so consumers update local copies without calling back to the producer — trading storage for autonomy.
Definition
Event-carried state transfer is a data replication pattern where events carry the complete current state of an entity, not just the change. Consumers maintain their own local replica and never query the producer for details. The producer gains independence from consumer read load; consumers gain availability and latency independent of the producer.
Context and scope
Applied in microservice landscapes wanting service autonomy: order service publishing order state that search, analytics, and notification services each cache locally. Contrasts with event notification and event sourcing.
Common misconceptions
- Bigger events are always wasteful — the payload buys consumer autonomy and producer insulation; the waste appears only when consumers use a sliver
- Consumers can always fetch missing data from the producer — callbacks recreate the temporal coupling and availability dependency the pattern exists to remove
- The events are the system of record — producers still own the source of truth; replicas are read models that converge
Anti-patterns
- Publishing state events but designing consumers to call back for enrichment, recreating the coupling
- Embedding huge collections inside entity events and flooding the broker with megabyte messages
- Treating the local replica as authoritative and writing business decisions to it
Related concepts
Related examples
Authoritative source
https://microservices.io/patterns/data/event-carried-state-transfer.html
What it is
A notification event says something happened; the consumer must ask for details. A state transfer event includes the details. The first keeps events small but couples runtimes; the second decouples them at the cost of payload and replica storage.
How it works
The producer publishes the entity snapshot — or delta — keyed by entity id and version. Consumers upsert local tables, joining and querying locally. Missing events mean stale replicas: consumers track sequence numbers and request catch-up snapshots or compacted log replays. GDPR-style deletion requires tombstone events with the same discipline.
When to choose
Many services reading the same reference data, consumers needing low-latency reads without cross-service calls, and teams wanting independent deployment and evolution of read models. Avoid it for payloads that exceed broker limits or churn so fast that replicas thrash on updates.
Pitfalls
Replica drift is silent: consumers must monitor version lag. Schema evolution applies to the event contract, so producers must version payloads and upcast. Sensitive fields leak everywhere the event flows — field-level governance belongs in the contract review, not in after-the-fact audits.