CQRS and Event Sourcing as an antidote for problems with retrieving application states

Łukasz Kucik - June 1, 2018

Nowadays, every developer is familiar with the standard architectural pattern MVC. Most of the applications are created around this approach. It allows us for creating big enterprise apps which are scalable and extensible, but recently we can hear more and more about CQRS/ES. Should these approaches be used together? What kind of problems can be fixed by them? Let’s have a look at what these patterns are and what are pros and cons of using them.

CQRS - pattern overview

CQRS (Command Query Responsibility Segregation) is a very simple pattern. It comes from CQS which stands for Command Query Separation and it was devised by Bertrand Meyer. According to this, methods in the system should be separated into two groups: commands that mutate the state and queries that return a value. Applying this idea to objects or components introduces a new concept - CQRS introduced by Greg Young. The main idea behind it is that classes or components within the application changing state (commands) should be separated from the components which getting the state of the application (queries).

Structure of CQRS part of our application can be illustrated by the following schema:

CQRS Pattern

Commands represent user intent. They contain all the necessary information about actions that user would like to perform.

  • Command Bus is a type of queue that receives commands and passes them to Command Handlers.
  • Command Handlers contain actual business logic which validates and processes data received in commands. Command handlers are responsible for generation and propagation of domain events to Event Bus
  • Event Bus dispatches events to event handlers subscribed for specific event types. Event bus can propagate events both asynchronously or synchronously if consecutive events are dependent.
  • Event Handlers are responsible for handling specific incoming events. Their role is to save the new state of the application in read repository, and perform terminal actions like sending emails, storing files etc.

Queries are objects, which represent the actual state of application available for a user. Getting data for UI should be done through these objects.

We can distinguish many advantages of CQRS approach including the following:

  • We can split development tasks between people more experienced who will be working on the business logic and those ones who will be working on queries part. We have to be careful because this advantage may hurt knowledge transfer.
  • We can achieve a great read/write performance by scaling commands and queries on multiple different servers.
  • Using two different repositories (read/write) which are synchronized gives us automatic backup without any additional effort.
  • Reads don’t hit write database, so they can go faster when using Event Sourcing.
  • We can structure read data directly for the views, without thinking about domain logic, which simplifies views and can improve performance.

Despite all the above benefits of using the CQRS pattern, we should be very careful using it. For a low complexity projects, with simple domain, where UI model corresponds closely to domain, CQRS would be a great example of over engineering and redundant complexity. Moreover, the implementation of CQRS for projects with low number or requests won’t bring significant performance increase.

Event Sourcing - case study

At Nexocode we were trying to solve a problem of storing the previous states of the domain objects that influenced current state. Particularly, we were interested in generating statistics at any point of time. We wanted to check the state of our aggregate from the last month, last quarter or any other date from the past. The problem was not easy. We could keep additional data in the database for particular ranges of time, but there were also some drawbacks to this approach. We didn’t know how ranges should look like and what data would be necessary for future statistics. To avoid those problems, we could make snapshots all aggregates every day, but it produces a lot of redundant data.

Event Sourcing seems to be the best solution for that problems. Event sourcing allows us to keep every change of aggregate state as events in a repository called Event Store. Publishing event by command handler should finish with saving event in write DB (event store) and initiating logic handled by event handlers. To create the current state of aggregate we need to run all events which create expected domain object and perform all changes to it. Below schema should explain that idea in a clear way:

Event Sourcing

We are able to specify some advantages of ES:

  • Time traveling. Possibility to recreate the state of specific aggregates in time. Every event contains a timestamp. It is not a problem to run events and stop them at a particular time based on these timestamps.
  • Natural audit. We can check who made a change and what was that change without any additional effort. Unlike system logs that can show changes history, events can tell the intent behind each change.
  • Ease of introducing corrects. When inconsistency appears in DB, we are able to reverse application state to a specific point in time, apply fixing event and further events.
  • Better debugging. If something goes wrong, we can prepare test environment and rebuild the state of application step by step from scratch by applying all events. Thanks to that, we can find the issue faster and in consequence, we can save a lot of time.

Aggregates

I used word aggregate many times in this article, but what does it mean? It is a concept that comes from Domain-Driven-Design (DDD) and it refers to the entity or group of related entities which are always kept in a consistent state. We can think of it as a box which accepts and handle commands (contains command handlers) and then generates events based on the current state (applying events on event bus). In our particular case aggregate root is composed of one domain object, but it can be composed of multiple objects. We have also to be aware that the whole application can consist of multiple aggregates and all events are stored up in one repository.

Conclusion

CQRS/ES can be a good alternative as a solution for specific problems. It can be introduced in some parts of the standard n-layer app and it can resolve non-standard problems where not only the current state is important, but also in places where we have to know how current state was built. Are CQRS and ES concepts that should exist together? In fact, no. Write DB can store only the current state. It wasn’t the case in our application and introducing CQRS only didn’t resolve our problem. We’ve implemented CQRS/ES using Axon framework for resolving some specific problems of one of the domain objects, especially gathering statistics. The next step is to prepare for recreating aggregate in time. In the near future, I’ll describe how CQRS/ES can be implemented with Axon framework and easily integrated with Spring Boot application.

You can find more details within following articles:

About the author

Łukasz Kucik

Software Engineer

Łukasz is a Software Engineer with industry experience building large-scale web applications. He provides full-stack solutions but mainly focuses on BE with Java, Kotlin, and Spring.
He believes that working in small Agile teams is the key to significant results, as good communication guarantees success. Łukasz's daily routine includes improving his coding skills by introducing clean code standards and refactoring.

Find us on

Need help with implementing AI in your business?

Let's talk blue circle

This site uses cookies for analytical purposes.

Accept Privacy Policy

In the interests of your safety and to implement the principle of lawful, reliable and transparent processing of your personal data when using our services, we developed this document called the Privacy Policy. This document regulates the processing and protection of Users’ personal data in connection with their use of the Website and has been prepared by Nexocode.

To ensure the protection of Users' personal data, Nexocode applies appropriate organizational and technical solutions to prevent privacy breaches. Nexocode implements measures to ensure security at the level which ensures compliance with applicable Polish and European laws such as:

  1. Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation) (published in the Official Journal of the European Union L 119, p 1); Act of 10 May 2018 on personal data protection (published in the Journal of Laws of 2018, item 1000);
  2. Act of 18 July 2002 on providing services by electronic means;
  3. Telecommunications Law of 16 July 2004.

The Website is secured by the SSL protocol, which provides secure data transmission on the Internet.

1. Definitions

  1. User – a person that uses the Website, i.e. a natural person with full legal capacity, a legal person, or an organizational unit which is not a legal person to which specific provisions grant legal capacity.
  2. Nexocode – NEXOCODE sp. z o.o. with its registered office in Kraków, ul. Generała Henryka Kamieńskiego 51, 30-644 Kraków, entered into the Register of Entrepreneurs of the National Court Register kept by the District Court for Kraków-Śródmieście in Kraków, 11th Commercial Department of the National Court Register, under the KRS number: 0000686992, NIP: 6762533324.
  3. Website – website run by Nexocode, at the URL: nexocode.com whose content is available to authorized persons.
  4. Cookies – small files saved by the server on the User's computer, which the server can read when when the website is accessed from the computer.
  5. SSL protocol – a special standard for transmitting data on the Internet which unlike ordinary methods of data transmission encrypts data transmission.
  6. System log – the information that the User's computer transmits to the server which may contain various data (e.g. the user’s IP number), allowing to determine the approximate location where the connection came from.
  7. IP address – individual number which is usually assigned to every computer connected to the Internet. The IP number can be permanently associated with the computer (static) or assigned to a given connection (dynamic).
  8. GDPR – Regulation 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of individuals regarding the processing of personal data and onthe free transmission of such data, repealing Directive 95/46 / EC (General Data Protection Regulation).
  9. Personal data – information about an identified or identifiable natural person ("data subject"). An identifiable natural person is a person who can be directly or indirectly identified, in particular on the basis of identifiers such as name, identification number, location data, online identifiers or one or more specific factors determining the physical, physiological, genetic, mental, economic, cultural or social identity of a natural person.
  10. Processing – any operations performed on personal data, such as collecting, recording, storing, developing, modifying, sharing, and deleting, especially when performed in IT systems.

2. Cookies

The Website is secured by the SSL protocol, which provides secure data transmission on the Internet. The Website, in accordance with art. 173 of the Telecommunications Act of 16 July 2004 of the Republic of Poland, uses Cookies, i.e. data, in particular text files, stored on the User's end device.
Cookies are used to:

  1. improve user experience and facilitate navigation on the site;
  2. help to identify returning Users who access the website using the device on which Cookies were saved;
  3. creating statistics which help to understand how the Users use websites, which allows to improve their structure and content;
  4. adjusting the content of the Website pages to specific User’s preferences and optimizing the websites website experience to the each User's individual needs.

Cookies usually contain the name of the website from which they originate, their storage time on the end device and a unique number. On our Website, we use the following types of Cookies:

  • "Session" – cookie files stored on the User's end device until the Uses logs out, leaves the website or turns off the web browser;
  • "Persistent" – cookie files stored on the User's end device for the time specified in the Cookie file parameters or until they are deleted by the User;
  • "Performance" – cookies used specifically for gathering data on how visitors use a website to measure the performance of a website;
  • "Strictly necessary" – essential for browsing the website and using its features, such as accessing secure areas of the site;
  • "Functional" – cookies enabling remembering the settings selected by the User and personalizing the User interface;
  • "First-party" – cookies stored by the Website;
  • "Third-party" – cookies derived from a website other than the Website;
  • "Facebook cookies" – You should read Facebook cookies policy: https://www.facebook.com/policy/cookies
  • "Other Google cookies" – Refer to Google cookie policy: www.google.com/policies/technologies/types/

3. How System Logs work on the Website

User's activity on the Website, including the User’s Personal Data, is recorded in System Logs. The information collected in the Logs is processed primarily for purposes related to the provision of services, i.e. for the purposes of:

  • analytics – to improve the quality of services provided by us as part of the Website and adapt its functionalities to the needs of the Users. The legal basis for processing in this case is the legitimate interest of Nexocode consisting in analyzing Users' activities and their preferences;
  • fraud detection, identification and countering threats to stability and correct operation of the Website.

4. Cookie mechanism on the Website

Our site uses basic cookies that facilitate the use of its resources. Cookies contain useful information and are stored on the User's computer – our server can read them when connecting to this computer again. Most web browsers allow cookies to be stored on the User's end device by default. Each User can change their Cookie settings in the web browser settings menu: Google ChromeOpen the menu (click the three-dot icon in the upper right corner), Settings > Advanced. In the "Privacy and security" section, click the Content Settings button. In the "Cookies and site date" section you can change the following Cookie settings:

  • Deleting cookies,
  • Blocking cookies by default,
  • Default permission for cookies,
  • Saving Cookies and website data by default and clearing them when the browser is closed,
  • Specifying exceptions for Cookies for specific websites or domains

Internet Explorer 6.0 and 7.0
From the browser menu (upper right corner): Tools > Internet Options > Privacy, click the Sites button. Use the slider to set the desired level, confirm the change with the OK button.

Mozilla Firefox
browser menu: Tools > Options > Privacy and security. Activate the “Custom” field. From there, you can check a relevant field to decide whether or not to accept cookies.

Opera
Open the browser’s settings menu: Go to the Advanced section > Site Settings > Cookies and site data. From there, adjust the setting: Allow sites to save and read cookie data

Safari
In the Safari drop-down menu, select Preferences and click the Security icon.From there, select the desired security level in the "Accept cookies" area.

Disabling Cookies in your browser does not deprive you of access to the resources of the Website. Web browsers, by default, allow storing Cookies on the User's end device. Website Users can freely adjust cookie settings. The web browser allows you to delete cookies. It is also possible to automatically block cookies. Detailed information on this subject is provided in the help or documentation of the specific web browser used by the User. The User can decide not to receive Cookies by changing browser settings. However, disabling Cookies necessary for authentication, security or remembering User preferences may impact user experience, or even make the Website unusable.

5. Additional information

External links may be placed on the Website enabling Users to directly reach other website. Also, while using the Website, cookies may also be placed on the User’s device from other entities, in particular from third parties such as Google, in order to enable the use the functionalities of the Website integrated with these third parties. Each of such providers sets out the rules for the use of cookies in their privacy policy, so for security reasons we recommend that you read the privacy policy document before using these pages. We reserve the right to change this privacy policy at any time by publishing an updated version on our Website. After making the change, the privacy policy will be published on the page with a new date. For more information on the conditions of providing services, in particular the rules of using the Website, contracting, as well as the conditions of accessing content and using the Website, please refer to the the Website’s Terms and Conditions.

Nexocode Team