CQRS and Event Sourcing Difference

Question

CQRS

CQRS was introduced by Greg Young; his explanation in 2010

CQRS is simply the creation of two objects where there was previously only one. The separation occurs based upon whether the methods are a command or a query (the same definition that is used by Meyer in Command and Query Separation, a command is any method that mutates state and a query is any method that returns a value).

Typically, this means that each of the objects will use a different representation of the data, so as to be fit for purpose. Common language here is to refer to a "write model" and a "read model". It is usually the case that changes will be made to the write model first, and propagate asynchronously to the read model.

As it happens, there's nothing magic about the number "2"; you could just as easily have 3 different representations as two.

The key benefit here is that you can tune the data structures for your read use cases and your write use cases independently.

Event Sourcing

Event sourcing a pattern for recording of state in a non-destructive way. Each change of state is appended to a log. Because the changes are non-destructive, we preserve the ability to answer queries about the state of the object at any point in its life cycle.

The use of events affords a more efficient use of storage space (relative to storing the complete representation of the state after each change) while retaining the semantic intent of the change (relative to just storing diffs)

Greg described event sourcing this way

storing current state as a series of events and rebuilding state within the system by replaying that series of events

CQRS + Event Sourcing

These techniques are frequently paired together, because the log, as a conceptual data structure, is not particularly efficient at supporting queries. You will normally want to condense the log into some other representation that is more suitable for reads (which are likely to be much more frequent than writes).

Thus, in the CQRS pattern, we typically use a log as the persistence model, and then from that log create query suitable representations of the object, and cache those representations such that queries can be supported quickly (accepting the compromise that the representation used in the query will not always reflect the absolute latest information available).

Lets take a simple real world example:

CQRS: We will use cache/redis/elasticsearch for read queries and database/mysql/mongo for write queries. This is what CQRS is exactly. Seperating the read and write logic is CQRS.

Event Sourcing: All Pub/Sub patterns that we use will comes under Event sourcing. Here we will publish messages as one event to queue(kafka/RabbitMQ) and subscribers will simply consume those messages by subscribing to those queues.

CQRS + Event Source: Lets take our above example only. How we should update the Read model (cache/redis/elasticsearch) when ever any update comes to Write model(database/mysql/mongo) ?

We can use Event Source here. When ever any update comes to database will create one event (containing the changes) and push that event to queue. Now Reader Model(elasticsearch) will subscribe to these queues and apply the events on top of its state. Thus we have maintained same state across read and write model.

CQRS:

CQRS stands for Command Query Responsibility Segregation. Introduced by Greg Young. Every method should either be a Command that performs an action or a Query that returns data. A command cannot return data and a query cannot change the data. Each model can be optimized for the specific context, and it also retains its conceptual integrity.

Event sourcing:

Event Sourcing is not necessary for CQRS. You can combine Event Sourcing and CQRS. This kind of combination can lead us to a new type of CQRS. It involves modeling the state changes made by applications as an immutable sequence or log of events. You may think about logging in your system and event logging, But to be honest event logging is not event sourcing. Event sourcing force the current state to be derived from history. If you can not reason about your current system from history you are not doing event sourcing. Indeed events are business facts.

In Domain Driven design events must follow Ubiquitous language and all the events in your system must be in past and named in past tense. Events are independent, I mean events should have enough data to describe their self.

Event sourcing is rising in popularity. Because it makes troubleshooting easier and has better performance characteristics; writes and reads can be scaled independently. Refers to GRASP event souring enable loosely coupled application architecture. Also, it enables to add more applications in the future that need to process the same event but create a different materialized view.