What is event sourcing?

Definition of Event Sourcing

Event Sourcing is an architectural pattern and a method of managing application state in which all changes in the state of an aggregate (domain object, such as an order or user account) are stored as a sequence of immutable events in chronological order. Instead of storing only the current state of the object as in traditional databases, the entire history of events that led to that state is preserved.

The current state of the aggregate can be restored (reconstructed) at any time by replaying the sequence of events from the beginning. This fundamental difference from the conventional CRUD approach (Create, Read, Update, Delete) opens entirely new possibilities for audit, analysis, and system design.

How Event Sourcing Works

In a system based on Event Sourcing, the data flow follows a clearly defined process:

Commands and Validation

Incoming commands (state change intentions) are validated by the aggregate. The aggregate checks whether the command is permitted in the current state and whether all business rules are satisfied. Only valid commands result in events being generated.

Event Generation

If the command is valid, the aggregate generates one or more domain events describing the fact that a state change has occurred. Examples include:

• OrderPlaced
• DeliveryAddressChanged
• ProductAddedToCart
• PaymentConfirmed
• OrderCancelled

Events are past facts and are immutable. They describe what happened, not what should happen. This distinction is fundamental to understanding Event Sourcing correctly.

Event Store

Generated events are stored in a special event store in the order in which they occur. The Event Store works like an append-only log, where new entries are added but existing ones are never modified or deleted. Each event is typically stored with metadata including a timestamp, aggregate ID, event type, sequence number, and the event payload.

State Reconstruction and Replay

The aggregate updates its internal state by applying the logic contained in the handling of each event. To obtain the current state of an aggregate (for example, when handling the next command), the system reads all events related to that aggregate from the Event Store and replays them one by one, applying state changes sequentially.

Snapshots for Optimization

For aggregates with long event histories, replay can become time-consuming. Snapshots periodically save the full state of the aggregate, so replay only needs to start from the last snapshot. The optimal snapshot frequency depends on the number of events and the desired load time. Common strategies include snapshotting every N events or based on time intervals.

Event Publication

Recorded events can be published to other parts of the system, for example through a message broker. This allows other components to react to events and update their own read models, forming the basis for CQRS integration and cross-service communication.

Event Sourcing and CQRS

Event Sourcing is frequently used in combination with the CQRS pattern (Command Query Responsibility Segregation). CQRS separates the write model (Commands) from the read model (Queries):

Aspect	Write Side	Read Side
Data model	Event Store with event sequences	Optimized read models (projections)
Optimization	Validation and consistency	Query performance
Scaling	Optimized for write load	Optimized for read load
Updates	Through command processing	Through event projection

This combination enables the creation of different read models for different requirements without affecting the write model. An e-commerce system might have separate projections for order status, revenue reports, and inventory overviews, all fed from the same event stream.

Benefits of Event Sourcing

The Event Sourcing pattern provides several significant advantages:

• Complete change history (Audit Log): Keeping a full history of events provides a natural audit log to track exactly how the aggregate’s state changed over time and why. This is invaluable for compliance, regulatory requirements, and dispute resolution.
• Past state reconstruction: The system’s state can be reconstructed for any point in the past. This is extremely valuable for debugging, analysis, compliance requirements, and testing.
• Flexibility in creating read models: Recorded events can be used to build many different read models (projections), optimized for different analytical needs or application views, without affecting the write model.
• High write performance: Writing events to the append-only log is typically a very fast operation since no locks on existing records are required.
• Natural support for EDA: Event Sourcing fits seamlessly into event-driven architecture, where events are the primary communication mechanism.
• Facilitated debugging: The complete event history makes it easier to understand what led to an erroneous state and enables targeted reproduction of problems.
• Temporal queries: Queries can be executed against the system’s state at any arbitrary point in time, which is invaluable for compliance and analysis.

Challenges and Complexities

The implementation of Event Sourcing also comes with several challenges:

Conceptual Complexity

Event Sourcing is a more complex pattern than the traditional CRUD approach. The entire development team must understand and consistently apply the concept. The paradigm shift from thinking in states to thinking in events requires adjustment and training.

State Replay Performance

Recreating state from a long history of events can be time-consuming. Without snapshots, load time grows linearly with the number of events. A well-thought-out snapshot strategy is therefore essential for performance.

Event Versioning

As the system evolves, the structure of events may change. Implementing mechanisms for handling different versions of events (event schema versioning) is one of the greatest practical challenges. Common strategies include upcasting (transforming old events when reading) and the use of schema registries.

Event Store Management

The event store becomes a key component of the system and requires proper management, scaling, and backup. The choice of the right technology, whether specialized solutions like EventStoreDB or generic systems like Apache Kafka, depends on specific requirements.

Eventual Consistency

In distributed systems where events are propagated asynchronously, read models can be updated with some delay. This eventual consistency must be accounted for in the user interface and business processes, and users must be informed when they are viewing potentially stale data.

Deletion and Data Protection

Since events are immutable, deleting data as required by regulations like GDPR presents a particular challenge. Solution approaches include crypto-shredding (encrypting personal data and deleting the key) and event transformation techniques.

Implementation Technologies

Several technologies are available for implementing Event Sourcing:

• EventStoreDB: A database specifically designed for Event Sourcing with built-in support for streams, projections, and subscriptions.
• Apache Kafka: As a distributed commit log, Kafka is well-suited as an event store for high-volume scenarios.
• Axon Framework: A Java framework that supports Event Sourcing and CQRS out of the box.
• Marten: A .NET library that uses PostgreSQL as an event store.
• Relational databases: With appropriate schema design, PostgreSQL or other relational databases can also serve as event stores for simpler use cases.

When to Use Event Sourcing

Event Sourcing is particularly valuable in systems where:

• A complete history of state changes is critical (audit, compliance).
• The ability to reconstruct past states is needed for debugging or analysis.
• Great flexibility in creating different data views (read models) is required.
• The system architecture is event-driven (EDA).
• Complex business logic exists alongside a need for cause-and-effect analysis.
• Industry-specific compliance requirements apply (finance, healthcare, regulation).

For simple CRUD applications without special audit or analysis requirements, Event Sourcing is often over-engineered and adds unnecessary complexity. Teams should carefully evaluate whether the benefits justify the additional architectural investment.

Event Sourcing and Staffing Needs

ARDURA Consulting supports organizations in acquiring software architects and backend developers with deep experience in Event Sourcing and CQRS. Implementing these advanced architectural patterns requires specialized expertise that is in high demand on the job market. Through experienced specialists, companies can leverage the advantages of Event Sourcing while effectively managing the associated challenges and avoiding common pitfalls during implementation.

Summary

Event Sourcing is a powerful architectural pattern that changes the way we think about application state management by focusing on recording the history of events rather than just the current state. It offers unique benefits in auditing, flexibility, debugging, and analysis, but also introduces additional complexity, particularly around event versioning, data consistency, and data protection. In combination with CQRS and an event-driven architecture, Event Sourcing reaches its full potential, enabling the construction of robust, scalable, and traceable systems for demanding business applications. Organizations adopting this pattern should invest in team education and choose the right tooling to succeed in their implementation journey.