CQRS and Event Sourcing

Table of contents

Reading Time: 3 minutes

People often get confused in Event Sourcing and CQRS(Command Query Responsibility Segregation) thinking that both are same. But they are different techniques which can be combined together to create more resilient and elastic applications.
In this blog, we will discuss the difference between CQRS and Event sourcing and how they can be combined.

What is Event Sourcing?

Storing all the changes (events) to the system, rather than just its current state, which are immutable facts of things that have happened. In addition to persisting state, it persists an audit log. Log captures the history and can be used to fix issues with the state.
In a nutshell, Event sourcing is storing current state as a series of events and rebuilding state within the system by replaying that series of events.

In case of thousands of events replaying those events can be problematic. We can occasionally persist a snapshot that captures the current state of an object. When we recover we can replay from the most recent snapshot. We could delete the snapshot at any time. That’s how we can leverage snapshots in order to speed up load time.

Event sourcing your aggregates

Event sourcing when combined with DDD usually starts with Aggregates or entity. Entities or Aggregate roots create events which are then persisted. A problem arises when you need to perform queries that can’t be answered by a single aggregate root. In other terms, Aggregate root should have a single responsibility. The model that we use to persist is often not compatible with the model we want to use for queries. This separation of the write-side and the read-side of the persistent data is often referred to as the CQRS (Command Query Responsibility Segregation) pattern.

A benefit of this pattern is the separation of concerns between the write and the read-side. Then the entities can focus on the updating commands and the read-side can be optimized for various queries and reporting jobs. A single conceptual model that tries to encapsulate both read and write operations may do neither well.

What is CQRS(Command Query Responsibility Segregation)?

CQRS (Command Query Responsibility Segregation) is a way to dissociate writes (Command) and reads (Query). It means we can have one database to manage the write part. Whilst the read part (also called view or projection) is derived from the write part and can be managed by one or multiple databases (depending on the use cases). Most of the times, the read part is asynchronously computed which means both parts are not strictly consistent. We are going to come back on this point later on.

CQRS + Event Sourcing

Simple CQRS(without Event Sourcing) has the same consistency guarantees as any non-CQRS based. Applying Event Sourcing on top of CQRS means persisting each event on the write part of our application. Then the read part is derived from the sequence of events.

CQRS/ES can be implemented with different consistency concerns for read and write models.

In Write model strong consistency is important. Pure reads are never strongly consistent that means they are Eventually consistent. Basically, In Read model, we deal with stale data.
Read model can be cached which allows for high scalability and Write model can be scaled using Sharding.
As Write model is strongly consistent, therefore sacrifices have to be made in availability while Read model is Eventual Consistent so high availability is possible.
In failure, the system disables Write while Read is still there.

Conclusion

Despite these benefits, you should be very cautious about using CQRS. Many information systems fit well with the notion of an information base that is updated in the same way that it’s read, adding CQRS to such a system can add significant complexity. I’ve certainly seen cases where it’s made a significant drag on productivity, adding an unwarranted amount of risk to the project, even in the hands of a capable team. So while CQRS is a pattern that’s good to have in the toolbox, beware that it is difficult to use well and you can easily chop off important bits if you mishandle it.

Hope you liked the bog. Stay tuned!! 🙂