Stackbook Logo
messagingestablished · medium operational burden

Event-Carried State Transfer

Also known as: fat events, state replication via events

Intent

Include enough entity state in each event that consumers can maintain a local copy and avoid calling the source service.

Problem

Services that look up data from another service at request time inherit its latency and outages. Thin events force every consumer to call back for details, creating coupling and load spikes.

Forces

  • •Runtime dependence on another service hurts availability
  • •Consumers need only a subset of the data
  • •Local copies can go stale
  • •Event size and privacy exposure grow with content

Solution

Overview

With event-carried state transfer, the event is the data feed. A CustomerUpdated event includes the new address and tier, so the billing service never needs to ask.

The trade is explicit: consumers gain autonomy and give up immediate consistency.

Contrast it with the thin notification style, where an event only says that customer 42 changed and consumers must call back. That is simpler on the wire but creates a thundering herd of callbacks and reintroduces runtime coupling. State transfer shifts the cost to storage and to schema discipline.

How it works

The owner emits versioned state. Consumers upsert only if the incoming version is newer than their stored one.

event = {type: "CustomerUpdated", id: "c42", version: 7,
         data: {tier: "gold", country: "KE"}}

UPSERT customers_copy SET data = :data, version = :v
  WHERE id = :id AND version < :v;

Keeping replicas healthy needs tooling. A compacted topic retaining the latest event per key lets a new consumer rebuild by reading from the start. Periodic full snapshots or a reconciliation job compares replica counts and checksums with the source. Decide ownership clearly: only the source service writes the entity, and every copy is read-only.

Pitfalls

  • No version field, so reordering corrupts replicas.
  • Publishing the entire entity, including fields consumers should never see.
  • No bootstrap path for a new consumer; use compacted topics or snapshots.
  • Treating the copy as authoritative and writing back to it.

Key takeaways

  • Carry state so consumers can work offline from the source.
  • Version events and ignore stale ones.
  • Minimize fields to what consumers need.
  • Provide snapshots for bootstrap and repair.

✓ When to Use

  • •Consumers need reference data such as customers or products often
  • •Source service availability must not affect consumers
  • •Read-heavy workloads can tolerate eventual consistency

✗ When Not to Use

  • •Consumers need strongly consistent, current data
  • •Data is highly sensitive and should not be copied
  • •Data volume per change is very large

Pros

  • +Consumers stay available when the source is down
  • +Lower read latency and load on the source
  • +Loose runtime coupling

Cons

  • −Data duplication and eventual consistency
  • −Larger events and schema coupling
  • −Bootstrap and repair of replicas needed

Cost Profile

Infrastructure

Medium - broker and local stores

Operational

Medium - replay and rebuild tooling

Cognitive

Medium - staleness reasoning

Failure Modes

  • Out-of-order events overwrite newer state with older

  • Consumer misses events and drifts silently

  • Sensitive attributes leak into many stores

Real-World Examples

Alternatives

    Related Patterns

    • publish-subscribe
    • event-driven-architecture

    Competency Domains

    data statedistribution communication