Event-Carried State Transfer

Embed the current state of the changed entity directly in each event payload ("fat event"), so consuming services can update their local read models without making synchronous API calls back to the source service: eliminating downstream query fan-out and reducing coupling between services.

Thin events (ID-only) require consuming services to call back to the source service for entity data, creating synchronous coupling, a query fan-out under high event rates, and cascading failures if the source service is unavailable. ECST eliminates this by carrying the data in the event itself.

In event-driven systems, services emit events when their state changes. A "thin event" carries only a reference: {"type": "order.updated", "order_id": "abc123"}. Consuming services that need order details must call the Order service synchronously to fetch them. Under high event rates, this produces a downstream query storm: every event triggers one or more round-trip API calls back to the source.

Event-Carried State Transfer (ECST) embeds the current entity state in the event: {"type": "order.updated", "order_id": "abc123", "status": "shipped", "total": 99.99, ...}. Consuming services update their local projections directly from the event payload with no callback needed. The Order service emits once; all consumers derive state locally.

ECST is particularly valuable for read model projections in CQRS architectures: the query side maintains a denormalized read model rebuilt from event streams. When an order is updated, the search service, analytics service, and notification service all update their own representations using the event payload: no synchronous call back to the Order service.

Trade-off: events become larger. For entities with large state (documents, configurations), the event payload can grow to hundreds of kilobytes. Kafka's default message size limit (1 MB) must be respected. For very large entities, a reference to a content-addressed snapshot store (S3 object key) may replace the inline payload.

Distinction from event sourcing: ECST events carry current state, not deltas. Event sourcing events carry the change (what happened). ECST consumers get the full current state and overwrite their projection; event sourcing consumers apply deltas incrementally.

An Avro or Protobuf schema for a fat order event typically looks like:

message OrderUpdatedEvent {

string event_id = 1;

string order_id = 2;

google.protobuf.Timestamp occurred_at = 3;

OrderStatus status = 4;

repeated OrderItem items = 5;

int64 total_cents = 6;

string customer_id = 7;

}

A schema registry (Confluent or Apicurio) registers the event schema to enforce backward compatibility, so consumers can read events produced by both older and newer schema versions. For large entities, store the full payload in S3 or GCS with a content-addressed key and embed only the key and metadata in the event: {"type": "document.updated", "doc_id": "...", "version": 42, "payload_key": "s3://bucket/docs/abc123/v42.json"}.