CQRS ❤️ Event Sourcing
With the introduction of MVC pattern, backend developers learned to create a set of models which carries the state from the db to the view or vice versa. We use the same set for reading and writing the data.
During read operations, a set of wrappers on the top of these models allow us to write specific conversion or formatting logic to represent the data on UI. The approach works fine for a simple application, but fails when there is a large difference between number of reads and writes. This situation becomes a perfect use case to apply CQRS.
Command Query Responsibility Segregation (CQRS)
The CQRS pattern suggests dividing the common set of models into two: One set of models for write operations whereas another set of models for read operations. The former is called Commands and the latter is Queries.
CQRS in simple words means separating reads from writes
Obviously there has to be separate handlers for both commands and queries. This allows you to apply specific aspects on individual set to improve the overall performance.
The diagram shows the same db being used for both the models. But we can go ahead dividing the db into read and write db. That approach can lead to extra complexity of synchronising write db with read db. But almost all relational database providers in the market provide the read-write clustering with minimal configurations.
The CQRS pattern originated under domain driven design. It is not very effective to implement CQRS for a very simple CRUD application e.g. Guestbook. Moreover, it is not wise to apply CQRS to entire large scale application blindly.
CQRS can be a good tactic but not a strategy
This may result into multiple models scattered around the application. Think which part of your application can be best benefitted by CQRS and apply it as a tactic to tame one specific problem at a time.
Event Sourcing (ES)
On the other hand, when you hear CQRS, you may also hear about Event Sourcing. It is indeed interesting to see what Event sourcing being a pattern in Event Driven Architecture has to do with CQRS.
Event sourcing refers to the practice where all the changes to the application state are stored as a sequence of events
The state change should be carried out as an event and once an event occurred, the event itself can not be changed. If the state change was not desired, a reciprocating event has to be generated. These events can be stored in a special store called Event Store. The number of events in the event store will grow enormously as time passes. Due to which we have to create a snapshot that represents the state at a given time.
Thumb Rule: Existing events can never be changed or deleted
The ES pattern is great to preserve a detailed audit log. It also allows to revert back at a given time in the past. Immediately you will try to recall such a use case; I think Git will be on the top.
With ES, the writes are in form of events which are saved to Event store. The read is an aggregation of the state changes stored in different events. Many times, a projection is created to represent the current state of a given entity. The read operations are performed on these projections. Hence, ES becomes a natural use case for CQRS.
The above diagram explains this combination. Please note that the dotted flow is only for explanation.
CQRS ❤️ Event sourcing but CQRS ≠ Event Sourcing
In my opinion, it is not mandatory to club ES always with CQRS or vice versa but when used together, the solution is quite easy to understand.
What’s next ?
I know, it is too much of theory. I will soon write another article with a small demo on how to implement CQRS + ES based application using Axon Framework.
Stay tuned till then.
