Choosing between event sourcing and state sourcing is not just a technical decision—it’s also a strategic one. In this article, we explain what each pattern means, their advantages and limitations, and in which scenarios each is most appropriate.
What is event sourcing?
Event sourcing is an architectural pattern based on storing every change in the state of an entity as an immutable event. Instead of saving the final or current state, the system stores the complete sequence of events that led to that state. These events are recorded chronologically and become the system’s single source of truth.
For example, instead of storing that a bank account has a balance of 300 units, the system stores all relevant events: when the account was created, when deposits or withdrawals were made, and the corresponding amounts. To determine the current state, the system replays the entire sequence of events from the beginning.
Advantages of event sourcing
One of the main advantages is full traceability. With event sourcing, you can know exactly what happened, in what order, and when. This makes it ideal for sectors that must comply with strict regulations or need to audit system behavior, such as finance or healthcare.
Another key advantage is the ability to “travel through time.” Since you have the complete event history, you can reconstruct the state of an entity as it was at any point in the past. This is useful for testing and forensic analysis.
Additionally, event sourcing enables integration with other systems through published events. The same events that change internal state can be consumed by other services for synchronization or automated responses.
Disadvantages of event sourcing
However, this approach also has costs. The main one is its technical and conceptual complexity. Implementing event sourcing requires carefully defining events, ensuring immutability, versioning them when changes occur, and creating mechanisms to rebuild state from long sequences of events.
Another disadvantage is potential performance impact. Rebuilding the state of an entity with hundreds or thousands of events can be costly if additional mechanisms, such as snapshots (checkpoints of current state), are not implemented.
Finally, event sourcing demands a significant learning curve for development and operations teams. Not every use case justifies this investment.
What is state sourcing?
State sourcing, on the other hand, is the traditional approach in which the system directly stores the current state of an entity. Every time a change occurs, the new state overwrites the previous one. This is the model used in CRUD (Create, Read, Update, Delete) applications.
In this approach, an application stores the latest version of the state—for example, the current balance of a bank account—without retaining details of how that value was reached. If a history is needed, an additional auditing or logging mechanism must be built, which implies more effort and maintenance.
Advantages of state sourcing
The main advantage of this pattern is its simplicity. It is easy to implement, widely understood by development teams, and compatible with most relational and non-relational databases.
It also offers immediate efficiency for reads. Since the current state is directly available, query operations are typically faster and simpler than in event sourcing.
Moreover, most frameworks, ORMs, and analytics tools are designed to work with data models based on state sourcing, which reduces technical friction.
Disadvantages of state sourcing
The main disadvantage is the loss of traceability. Once the state is updated, information about how and why that point was reached is lost—unless a specific solution is implemented to preserve that history.
This also poses a challenge for industries where transparency is essential. State sourcing alone does not easily allow for reconstruction of decision or transaction context.
Another limiting factor is its lower adaptability in event-driven distributed architectures, where changes need to be propagated asynchronously across multiple services.
When to choose event sourcing
Event sourcing is recommended when a complete history of changes is needed, when strong auditability is required, or when events can serve as a means of integration between services.
Typical use cases include financial systems, e-commerce platforms with complex order logic, multi-stage business process management, and any regulated context that demands detailed accountability.
It is also highly useful when business logic evolves over time, as it allows past decisions to be reanalyzed under new rules or corrected retroactively.
When to choose state sourcing
State sourcing is the best option when simplicity, development speed, and read efficiency are more important than traceability. It is ideal for administrative applications, internal tools, dashboards, or systems where data changes infrequently or doesn’t require detailed history.
It is also the most common approach for early-stage startups, where the priority is to launch quickly without adding unnecessary complexity.
In general, if the system can operate without the ability to reconstruct the past, and if state changes don’t need to be propagated or processed as independent events, state sourcing is usually sufficient.
Practical considerations
Before choosing between event sourcing or state sourcing, organizations should consider the following factors:
- Do we need a detailed history of every change?
- What would be the impact of losing traceability over state?
- Will the system need to integrate with other services via events?
- Do our teams have the technical expertise to manage event-based architectures?
- What are the implications of each model in terms of maintenance, testing, and evolution?
In many cases, a hybrid approach is also possible. Some entities may benefit from event sourcing, while others may remain in a simpler state sourcing model. The challenge lies in correctly identifying which parts of the domain require which level of sophistication.
Choosing between event sourcing and state sourcing is not a minor decision. It affects not only the technical architecture of a solution but also the organization’s ability to scale, adapt, and respond to audits or incidents.
