Event Sourcing and CRQS: Match Made in Heaven — Part2

Muhammad S Tahir
Nov 7 · 4 min read

As architects and engineers, we are constantly challenged to build better software. The drawbacks of traditional architecture mentioned in Part1 of this blog series can be avoided by adopting different domain modeling techniques. We can build one such architecture by fusing Event Sourcing and CQRS technologies together.


Event Sourcing:

Event Sourcing involves modeling of domain objects in a way that it produces a stream of immutable events every time domain state changes. In this approach, domain state changes are captured as events and persisted in an event store.

As apparent from the diagram, event sourcing will help us with traceability and auditability aspects. These events are immutable; once they are persisted in the event store, they can not be modified. If there is an error, it can only be corrected by adding a corrective event to undo the previous action. As these events are immutable, the data store technology can be append-only. This architecture simplifies the database design making it much more scalable because there is no need for a locking mechanism. One such database for this purpose is Cassandra, which is designed to withstand heavy write loads and is a highly scalable data storage system. As these events are immutable, they can be shared freely across multiple instances of the application without any need for locking.

In order to get to the current state of the domain these events are replayed from inception to the last event. This will become more apparent when we review the concrete example in Part3.


CQRS (Command Query Responsibility Segregation):

CQRS stands for Command Query Responsibility Segregation, in which read views are modeled separately than write views. In this model, any state change is modeled as a Command. This command is validated for the correctness and is applied to the domain to produce a new state e.g., AddressUpdateCommand will result in an updated Address. Whereas reading the current state of the domain is modeled as Query. e.g. AddressLookupQuery will search for a particular address based on the query criteria and return the results without altering the state of the Address.

CQRS architecture can help avoid a single point of failure e.g. if the write database is down application will continue to service read-only requests. In contrast, if the read database is down, application can still intake state changes. CQRS also helps with scalability, by separating reads and writes logic, making them scale independently based on the requirements of the application.


Event Sourcing with CQRS:

By combining Event Sourcing and CQRS architecture we can build a software system that can help us build scabale, reliable, auditable systems with built in traceability. However, keep in mind that this technique comes with another set of challenges that may require careful thinking to avoid costly migrations later on. Also, we need to understand that systems built with Event Sourcing and CQRS technologies are eventually consistent.

We saw that Event Sourcing and CQRS solves some of the challenges we discussed in Part1. However each one by itself does not solve all the cocerns. Therefore when we combine them together it feels like a match made in heaven as the combination can address all the issues that traditional applications suffer from.

If the correct technology stack is selected, it can automatically propagate events to the rest of the ecosystem where they can also react to those events. e.g., when the AddressChangedEvent is published, other applications listening to these events can update Addresses in their system. This can help with the Domain state synchronization issue, which can help tremendously in a microservices architecture.


Before diving into some concrete examples lets first understand some nomenclature

Domain: A concept that models an object in the system. In an event-sourced system, it is also referred to as an Aggregate.

Event: Captures the change of domains state, and represents something that has happened in the past, it uses past tense in its name e.g. AddressChangedEvent

Event Store: An append-only data storage which captures the timestamped stream of events generated by the application. It could be a SQL or NoSQL database e.g., Cassandra

Command: A command is a message sent to the system to change its state. It encapsulates details about what to change. Hence commands are intended to produce side effects in the system.

Query: A read operation executed against the Domain Store

Domain Store: A data storage layer designed for optimized reads which hold the current state of the domain.e.g ElasticSearch

Muhammad S Tahir

Written by

Highly accomplished visionary hands on CTO having extensive Blockchain, FinTech and AdTech experience with range of companies.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade