Event Sourcing
Bu link aracılığı ile yazının Türkçe versiyonuna erişebilirsiniz.
Event-Sourcing and CQRS are different software development patterns that are often mentioned together. There is no obligation to use them together. Therefore; we will examine the two patterns separately, not together. Then we will talk about why these two patterns are often mentioned together.
Note: You can access the article on CQRS via this link. I recommend you to read before coming to the section where we explain why Event Sourcing and CQRS patterns are frequently mentioned together.
What is Event?
First of all, we can start with what the word Event means for us in the software industry and in this article. Event is the situation that occurs as a result of executing certain actions in the system upon a request. Briefly; it can also be called the occurrence of an occasion. For example; We can name the situation that occurs as a result of the request of a user to open an account on the system as “UserCreated”.
Note: Event is called an action on the system. It ends with past tense suffix.
What is Event Sourcing?
Event Sourcing is a method shaped on the main idea of collecting the events that have occurred in our system.
How Event Sourcing Works?
Objects that have an identity in the software world, which are some of the main parts of the system, are called entities.
In the traditional software development technic, an entity is produced and then stored in a data storage. Then, if a change in the status of this entity is required, the changes are executed directly on the copy of the entity in the data storage. That means; after each request is executed, the final version of the entity is stored in our data storage environment.
In systems developed with Event Sourcing, the latest status of the entities are not recorded. Instead, events affecting the state of the entities are recorded. When the query is sent by the client and the final status of the entity is requested, the system combines the existing event information and provides the necessary information.
Let’s explain this process with example. Let’s assume that there is an entity that represents the user in a system we have developed. Let us assume that user have information such as Name, Surname, Email, Email Verified, Password. Let us also assume that he performs the following actions, respectively.
- User opened an account with email and password information
- Updated username and surname
- User confirmed their email account
When we store user data with the traditional system, the content of our data storage environment can be as follows.
T1
T2
T3
In the Event Sourcing, the sample content that may occur if the same actions are carried out can be as follows.
T1
T2
T3
It is now possible to create the status of the user presence at any time with the Event Sourcing method. For this, we need to obtain all event information that took place before our requested time. We then execute the data of the occurring states on an empty user object, respectively, according to the date of occurrence. The user object we eventually acquire will be telling us the status of the user presence when we request it.
Event Sourcing vs Traditional Software Development Technique
As can be seen in the example above; in the traditional software development method, we keep the latest version of our continuous existence. In such a system, we will not be able to return to the state of the user at any time. In the In the Event Sourcing method, we can create the state of the system for a period of time that we desire.
Unlike the traditional software development method, in Event Sourcing method, new records are added to our data storage as long as the events occure on the system. Since an incident does not change or cannot be undone, updates and deletions are not available.
However when it comes to data reading, if performance comparison is made, the traditional method gives faster results than the Event Sourcing. In the Event Sourcing when the client requests the data, the breakdown of the events related to the entity is obtained. The state of the data is created from this transcript. It is obvious that the process of generating data from events will yield slower results compared to the traditional method where the data is kept ready.
Another process that is easy in the traditional method is to make inquiries on fields such as name and surname. However in the Event Sourcing method, it is not possible to query your users with data other than using what we call the relationship key.
We can solve the last two problems that occur when using Event Sourcing method (re-creating the entity every time and filtering the asset according to its areas) together with CQRS. For this reason, Event Sourcing and CQRS are frequently mentioned together.
Event Sourcing and CQRS
We know there are reading and writing models on the CQRS pattern. In the Event Sourcing method, it is mentioned that the event which affects the state of the entity is stored, not entity’s last state. Let’s combine these two pieces of information.
Let’s consider events as a writing model and the final state of an entity as a reading model. Let the client start an operation to change the state of the entity. Let’s keep the event information resulting from the operation in our system as a writing model. In this case, depending on our writing model, let our process be triggered and update our reading model. As a result, we had the Event Sourcing structure thanks to the writing model in our system. It is possible for us to reach the state of our system at any time we desire. In addition, we solve our querying and performance problems by using the reading model.
Although the above system sounds good, it is not used in every situation. Setting up this type of system is more complex than a traditional built software. Due to this complexity, maintenance and maintenance costs are also very high.
