Introduction to CQRS and Event Sourcing – Part 1

CQRS stands for Command Query Responsibility Segregation, which means that methods of the backend are either a query or a command, where queries doesn’t change the state of the domain, while the commands change the state but doesn’t return results.

Originally, CQRS is not an architecture, it is a simple pattern that distinguish between methods that mutates state and methods that return values.

Having this simple principle, opens the doors for doing many interesting things that leads to different architectural styles, the largest benefit is that you recognize two different architectural properties when dealing with commands and queries… for instance, when you look into the load of your system most probably you will find that query part is taking most of the load while the write is minimal, so you take a step back and rethink again! Do I need to scale my services symmetrically in terms read and write operations? Will it be a waste of resources to not distinguish between my write services and read ones? If I have 8 servers does it make more sense to have 5 of them for read-only services and just 1 for write-only services?

Additional major concern comes to the table, is that do I need to have single model to serve both the read and write? What if my concern was to have very fast reading and I require to use different technology for that? Let say a sophisticated search engine like apache Solr, while I require a traditional RDBMS for the business domain itself!

By utilizing the Domain Driven Design principles and patterns, the architecture will evolve eventually into something similar to the diagram below:

In this blog series “Introduction to CQRS and Event Sourcing”, we’ll start by how we can implement such architecture using the following technologies and frameworks:

• RabbitMq as Message broker and Transport for messaging.
  
• Masstransit as Event & Command Buses on top of RabbitMq.
  
• NEventStore as Domain Model and Event sourcing.
  
• MySQL as Event-Store persistence.
  
• MongoDB as Read data store.