Event Sourcing Explained: Event Stores, Projections, Replay, and Schema Evolution

Event Sourcing Explained: Event Stores, Projections, Replay, and Schema Evolution

Event sourcing stores a domain's changes as an ordered, append-only sequence of events instead of storing only its latest state.

Events Are the Source of Truth

Instead of updating:

order.status = cancelled

you append a business event such as:

OrderCancelled

Current state is reconstructed by replaying the entity's event stream.

Good events describe business intent, not low-level database mutations.

Projections Make Reads Practical

Replaying hundreds of events for every UI request is inefficient. Consumers build materialized projections optimized for queries:

event stream → order summary table
event stream → analytics view
event stream → search document

These views are derived and can be rebuilt from the authoritative event history.

Use Optimistic Concurrency

Two writers can load the same stream version and attempt conflicting changes. Event stores commonly use expected stream versions so only one append succeeds; the loser reloads current state and reevaluates the command.

Snapshots Are an Optimization

For long streams, periodically store a state snapshot and replay only newer events.

The snapshot is not the source of truth. It should be rebuildable from the event stream.

Event Schemas Live a Long Time

Persisted events may exist for years. Avoid rewriting historical events casually.

Use additive compatible changes, event versions, tolerant deserialization, or upcasting when older schemas must be interpreted by newer code.

Corrections are normally represented by new compensating/corrective events rather than deleting history.

Event Store ≠ Message Broker

A broker such as Kafka is excellent for distributing events, but Azure's current guidance explicitly warns that a broker is not automatically a replacement for an event store with per-entity streams and optimistic concurrency semantics.

Use each component for the job it actually owns.

When Event Sourcing Is Worth It

Strong fit:

• audit/history is a core requirement
• domain decisions benefit from historical reconstruction
• multiple projections must be rebuilt from the same facts
• complex state transitions need a durable business history

For ordinary CRUD applications, the schema, projection, replay, privacy, and operational complexity often outweighs the benefit.

Final Takeaway

Event sourcing is valuable when history itself is business data. Keep events immutable and meaningful, use projections for reads, snapshots only for speed, and plan schema/privacy evolution before committing a domain to an append-only permanent history.

References

• Azure Architecture Center: Event Sourcing Pattern
• Azure Architecture Center: CQRS Pattern