Event Sourcing: Storing State as an Immutable Event Log

Q: Event Sourcing: Storing State as an Immutable Event Log

**event sourcing** stores the history of state changes as an immutable sequence of events rather than current state. To **GET** current state, replay all events. Benefits include full audit trail, temporal queries (state at any point in time), and natural fit with event-driven systems. Costs include **query** complexity, eventual consistency, and the need for snapshots as event logs grow.

Intermediate·3 min read·

NetflixGrabMicrosoftEventstoreLinkedInUber

Fast recall

Quick revision

Core answer

event sourcing stores the history of state changes as an immutable sequence of events rather than current state. To GET current state, replay all events. Benefits include full audit trail, temporal queries (state at any point in time), and natural fit with event-driven systems. Costs include query complexity, eventual consistency, and the need for snapshots as event logs grow.

Interview Answer3 min

Event sourcing is often confused with simply publishing events to Kafka.

It is actually a persistence model where the event log is the source of truth for entity state.
Instead of UPDATE orders SET status = 'SHIPPED' — which destroys history — you append an OrderShipped event.
Current state is always derived by replaying the full event stream from the beginning.

The real benefits:

A complete audit trail as the core mechanism, not an afterthought added later — every state transition is preserved by the fundamental design
Temporal queries become possible: "what was this order's state last Tuesday at 3pm?" — replay events up to that timestamp and you get the exact state
Since events are already persisted, publishing them to Kafka or other consumers requires no additional work — the event log IS the source

The real costs:

Reading current state requires replaying all events for an aggregate — for an order with 500 events, that's 500 state transitions before you can handle a new command; snapshots solve this by periodically materializing state so you only replay events since the last snapshot
Queries are harder — you cannot write a SQL JOIN across event streams, so you build read-side projections (materialized views) optimized for specific queries; this is why event sourcing almost always comes paired with CQRS
Schema evolution requires upcasters — you cannot ALTER a historical event, so breaking schema changes need transformers that convert old formats during replay

When to use it:

Domains where history is as important as current state: financial ledgers, order management, compliance-heavy systems
For standard CRUD with simple reporting needs, the operational complexity of snapshots, projections, and event schema evolution is not justified

I recommend event sourcing only when the domain genuinely requires a complete audit trail or temporal queries — the operational overhead is real and should only be accepted when the domain benefit is proportional.

Interview-ready guide

Interview answer

Event sourcing is often confused with simply publishing events to Kafka.

It is actually a persistence model where the event log is the source of truth for entity state.
Instead of UPDATE orders SET status = 'SHIPPED' — which destroys history — you append an OrderShipped event.
Current state is always derived by replaying the full event stream from the beginning.

The real benefits:

A complete audit trail as the core mechanism, not an afterthought added later — every state transition is preserved by the fundamental design
Temporal queries become possible: "what was this order's state last Tuesday at 3pm?" — replay events up to that timestamp and you get the exact state
Since events are already persisted, publishing them to Kafka or other consumers requires no additional work — the event log IS the source

The real costs:

Reading current state requires replaying all events for an aggregate — for an order with 500 events, that's 500 state transitions before you can handle a new command; snapshots solve this by periodically materializing state so you only replay events since the last snapshot
Queries are harder — you cannot write a SQL JOIN across event streams, so you build read-side projections (materialized views) optimized for specific queries; this is why event sourcing almost always comes paired with CQRS
Schema evolution requires upcasters — you cannot ALTER a historical event, so breaking schema changes need transformers that convert old formats during replay

When to use it:

Domains where history is as important as current state: financial ledgers, order management, compliance-heavy systems
For standard CRUD with simple reporting needs, the operational complexity of snapshots, projections, and event schema evolution is not justified

03 · Deep dive