Does every application with an event log use event sourcing?

No. Logs may be diagnostic while current-state tables remain authoritative.

Can a relational database implement an event store?

Yes, if its design provides the required append, ordering, concurrency and retrieval behavior.

Are snapshots mandatory?

No. They are an optimization for reconstruction; their usefulness depends on history length and workload.

AI Glossary / Data engineering and architecture / Intermediate

Event store

Definition

An event store is a persistent repository for ordered records of events that have occurred. In event-sourced applications, those events form the authoritative history from which current state and other views can be reconstructed.

What it means

A conventional record might say that an order is canceled. An event history can show that the order was created, an item was added, delivery details changed and cancellation was accepted. The stored facts describe the sequence of meaningful changes.

An event is different from a command. “Cancel this order” requests an action; “Order cancelled” records an accepted outcome. Persisting the request alone does not prove that the requested action succeeded.

The term describes a storage role, not one mandatory product. A purpose-built system or a suitably designed general database can provide it. A message broker distributes events to consumers, while an event store must preserve the history and retrieval guarantees needed by the application. One infrastructure component may support several roles, but those requirements must be assessed separately.

How it works

Events commonly belong to a stream associated with a particular entity or business consistency boundary. Records carry identifiers, event types, payloads and ordering information. Their schemas must remain interpretable as application code evolves.

To process a command, an application can load an entity's history, derive its state, check business rules and append the resulting events. A conditional append can reject the write if another operation changed the stream since it was read. This prevents treating a stale state as current without rechecking.

Read models, also called projections, process events into convenient query structures. A snapshot can record derived state at a known stream position so later reconstruction starts there and applies subsequent events. It should not be mistaken for the complete history.

Replay requires care. Rebuilding a report should not resend every historical notification or repeat an external action. Event identity, consumer checkpoints and idempotent handling help distinguish reconstructing state from executing new work.

Three practical examples

A booking application retains accepted reservations and cancellations so it can reconstruct availability and explain how it changed.
A document workflow records submitted, reviewed and approved events, allowing different views of its progression.
An AI-assisted editing system records accepted human changes separately from model suggestions, preserving which actions actually altered the document.

Think of it this way

Think of a scorekeeper recording every scoring event rather than only erasing and rewriting the current total. The total can be recalculated from the recorded sequence, and different summaries can be produced later.

The analogy has limits. Real business events have evolving schemas, permissions and retention requirements. A notebook also does not automatically prevent two people from recording incompatible actions at the same time.

Worked example

Rebuilding a simple inventory view

An invented stock stream starts at zero and records Received 20, Dispatched 6, Received 5 and Dispatched 3. Applying the events in order gives 0 + 20 − 6 + 5 − 3 = 16 units.

A snapshot after the second event would contain fourteen units and its stream position. Applying the remaining two events gives 14 + 5 − 3 = 16, the same result. Starting from the snapshot and replaying all four events would double-count earlier history.

Now imagine the final dispatch event is delivered twice to a projection. If the consumer applies both copies as new facts, the displayed total falls incorrectly to thirteen. Recognizing the same event identifier prevents that duplicate application.

This arithmetic assumes the events are valid and complete. An event store does not independently confirm that the physical warehouse received twenty items, nor does it make a missing business event appear.

Illustrative case study

A fictional workshop-booking service adopts event sourcing for schedule changes. Its event store preserves accepted bookings, reschedules and cancellations. A separate calendar projection makes the current schedule easy to query.

During a rebuild, the developers discover that replaying historical events also triggers old confirmation emails. They separate projection reconstruction from outward notifications and track which new events have already produced those effects. They test repeated deliveries as well as ordinary processing.

The service also records schema versions and maintains readers for older events. When an old event lacks a newly introduced field, the team defines an explicit interpretation instead of assuming the field was always present. The case illustrates operational responsibilities; it is not evidence that event sourcing is appropriate for every booking system.

Common misconceptions and mistakes

An event store is just a current-state table with timestamps. Its event history and reconstruction role are different.
Append-only storage eliminates concurrency problems. Competing commands still need a correct acceptance rule.
Replay should repeat every external effect. Rebuilding state usually requires separating historical processing from new actions.
Stored events are automatically complete truth. They preserve recorded facts under system guarantees, not independent proof of the outside world.

Business use

Consider an event store when the sequence of business changes is important and the application benefits from reconstructing or projecting that history. Assess the added complexity of event design, replay, schema evolution and operational recovery.

Define the required ordering and atomicity boundary. A sequence number inside one order's stream does not automatically order every event across the business. Ensure the read model's freshness is visible when it can lag behind accepted writes.

Plan retention and sensitive-data handling as part of the design. The intended append-only discipline does not remove lifecycle obligations. For AI systems, distinguish proposed actions, accepted actions and observed outcomes so the historical record remains interpretable.

Check your understanding

A projection begins from a snapshot at stream position 50. Should it apply events 1 through 60 to obtain state at position 60?

Answer: No. Assuming the snapshot correctly includes events through 50, apply events 51 through 60. Reapplying the earlier events would count them twice.

Related terms

Event sourcing
event stream
projection
snapshot
optimistic concurrency
idempotency
command
CQRS

Learn next

Read event sourcing and idempotency. Choose one business entity and distinguish its commands, accepted events, current-state projection and external effects before deciding how replay should behave.

Sources

Microsoft Azure Architecture Center, Event Sourcing pattern: https://learn.microsoft.com/en-us/azure/architecture/patterns/event-sourcing. Primary explanation of event stores, concurrency, projections and trade-offs.

AWS Prescriptive Guidance, Event sourcing pattern: https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/event-sourcing-pattern.html. Primary implementation guidance distinguishing commands, events and stored history.

Microsoft patterns and practices, Exploring CQRS and Event Sourcing: https://download.microsoft.com/download/e/a/8/ea8c6e1f-01d8-43ba-992b-35cfcaa4fae3/cqrs_journey_guide.pdf. Supporting reference for event storage and reconstruction. Examples are original illustrations.

Previous: Event extraction Next: Event tree analysis