Overview

Event Sourcing is a data management approach where, instead of storing only the current state of an entity, all changes are persisted as an ordered sequence of events in an event store. The current state of any entity is reconstructed by replaying its event history.

In the context of microservices architectures, Event Sourcing is used as a mechanism for publishing events that synchronise data between command and query models — complementing the CQRS pattern and Transactional Messaging patterns.

Problem

In a microservices architecture, a service often needs to publish an event whenever it updates its database — for example to notify CQRS read models or to trigger Saga steps. Guaranteeing that both the database update and the event publication happen atomically is challenging. Traditional approaches either risk publishing an event when the update failed, or missing the event when the publication failed.

Solution

Event Sourcing resolves the atomicity problem at the source: instead of updating a record and separately publishing an event, the service persists an event to an event store as its primary write operation. The current state of an entity is derived by replaying its events. Because the event itself is the state change, publishing it to other consumers is a reliable secondary operation over an append-only log.

The event store therefore acts as both a database and a message broker: it durably stores every state change, and other components (such as CQRS query services) subscribe to the stream to keep their read models up to date.

Relation to CQRS

As noted in the dissertation, CQRS requires the sending of messages or events to synchronise the command and query models. Event Sourcing can be used for this purpose, with the Eventuate Local framework providing event sourcing support for the local event store. The Eventuate Tram framework provides the complementary transactional messaging layer for publishing those events.

Similarly, the Axon Framework (an open-source Java framework) can be used for implementing CQRS together with Event Sourcing.

Trade-offs

Benefits

  • Atomic write and event publication — the event is the state change, eliminating the dual-write problem
  • Complete audit log — the full history of every entity is preserved
  • Enables temporal queries — reconstruct entity state at any point in time
  • Natural fit with CQRS — event streams feed query model updates

Drawbacks

  • Increased complexity — querying current state requires replaying events
  • Event schema evolution is challenging — old events must remain replayable after schema changes
  • Eventual consistency between the event store and derived read models

When to Use

Apply Event Sourcing when:

  • You need reliable atomic event publication alongside database writes (complements Transactional Outbox)
  • You are implementing CQRS and need a reliable event stream to keep the read model synchronised
  • A complete audit history of entity changes is a requirement

Avoid when:

  • Simple CRUD operations suffice — Event Sourcing adds significant complexity that is only justified by the benefits above
  • The team is not yet familiar with event-driven architecture and CQRS

References