Written by | Savan Kharod
Translated by | Hirakawa
With a thorough understanding of various architectural styles, designers can build new, reactive, and resilient large-scale applications. As a result, following these industry-proven standards saves time, guarantees reliability, and drives goals. After all, what reason do businesses have to spend time and resources reinventing the wheel?
But simply understanding different architectures, such as CRUD-based, microservices-based, and event-source-based, is not enough to make comprehensive decisions. We need to dig deeper into the details and understand their respective features, applicability and value. In this article, we'll take a look at crUD and event source architectures and think about why you should consider moving from the former to the latter.
What is CRUD?
CRUD is an abbreviation for create, read, update, and delete. It makes up the database's four commands, four self-explanatory commands, which are considered essential elements of persistent storage management. This model is widely used by businesses in various industries to track customer data, employee information, payment records, accounts, etc.
Let's quickly illustrate the general event flow for CRUD. Gary is browsing an e-commerce site. He added a console, a controller and a game to his shopping cart. At this point, the database of the shopping cart looks something like this:
If we add another item (such as a headset), the database will look like this:
If Gary deletes the headset, the table changes back to what it was before. In addition, if he adds another controller, the database will look like this:
Essentially, the database maintains tables by following a create-read-update-delete approach. The Update and Delete features are features of CRUD.
Limitations of the CRUD method
While the CRUD approach is favored for its lightweight and simple operation, it also has its own set of limitations, including:
For CRUD, the most common criticism is primitive and obsolete. It's not so much an architecture or design as it is a circular step to follow, whether it's building a database or an API.
CRUD relies on the persistence of state in the database. However, given the dynamic nature of current data manipulation events, the storage of such information can be wasteful and resource-intensive.
Although the CRUD architecture is simple, in the beginning it requires a lot of effort to write a lot of code. Still, crUD isn't up to the task when it comes to cloud load balancing.
While CRUD code may be simple to begin with, problems with state synchronization and troubleshooting arise when it starts sharing data with other services or microservices.
The complexity involved in the CRUD architecture will require an equally complex solution, which may extend to failure tracing, manual state logging, asynchronous batching, and so on. This consideration can be difficult both in terms of coding and integration.
In the CRUD model, entity instances are typically a dual representation, a mutable object in memory and a mutable row in a relational database table. Such a structure leads to a notorious object-relation impedance mismatch. Attempts to bridge this divide have further complicated the architecture.
What is the event source schema?
Event sources are a data storage technology that is considered an upgraded version of CRUD. It focuses only on creating and reading functionality, and completely omits the operation of updating and deleting values in the CRUD. More simply, you can't perform destructive actions through event sources.
So, how does it overcome the challenges crUD faces?
Here's an interesting point: Unlike the traditional approach followed by CRUD, event sources record changes one by one as a series of increments of the current state over time, rather than persisting the current state itself. In this way, event sources give state change traceability. In most cases, this design is often combined with domain-driven design (DDD) and command query responsibility separation (CQRS) design patterns.
To better understand the event source architecture, let's take Gary's bank account as an example. Let's say Gary has $2400 in his account. He bought the PS5 for $499. The e-commerce site offered him $49 cashback. In this case, the event source table would look like this:
By tracking withdrawals and deposits over a period of time, it can be calculated that his current account balance is $1950. The resilience of this state and the playback of events are called replays.
We can think of event sources as logs of customer activity.
If we look at Gary's activity from the perspective of an ecommerce platform, adding a console is the first event, adding a controller is the second event, and so on. In fact, the checkout process is also a separate event. If Gary accidentally adds three controllers to his cart (for example, events 1, 2, and 3) and then deletes one more, then the deletion is also a separate event: event 4!
Benefits of adopting an event source architecture
From a basic understanding of event sources, it seems to be a better and more complete alternative that overcomes the shortcomings of CRUD. To illustrate this further, let's take a look at the proven advantages of event sources.
Event sources follow an event-driven architecture that facilitates reliable release of events when state changes.
It overcomes object-relational impedance mismatches that occur in CRUD by persisting events instead of domain objects.
It maintains a record of a series of events that can be operated in an append-only state. By eliminating the need for state tracking and entity relationships, it is easier to write event source code that reads and writes to the database.
Because a log of how an entity arrives at the current event is preserved, the event source guarantees consistency between the audit data and the transaction data because they are identical. In addition, it is also a good failure insurance because the data can be reconstructed from the event log.
All events are simply appended to the existing database, and the update and delete functionality has been removed, and the event source schema focuses only on writes, which improves its performance.
Event sources allow the flow of events to be analyzed, which helps businesses derive critical information from them. They get a top-level view of all system activity without complicating write functionality.
Architectures that follow the event source model are easier to test and debug because commands and events can be mocked before they are introduced. In addition, event logs can serve as a good record of debugging activity, and if problems are found, event logs can be replayed in a controlled environment to understand what caused the exception.
It can store any type of information that any consumer can access as long as they are authorized. It allows the state of an entity to be queried by time at any time. Therefore, it is very flexible.
Event source applications are easier to migrate than monolithic schemas because they follow a microservices-based architecture. This is so because the business entities involved in the exchange of events are loosely coupled.
Conclusion
As more and more applications need to deliver real-time data in an orderly and asynchronous manner, so does the need for event sources. It's also a great way to consume and manage application log data at a network scale. In this case, the event source becomes a unique source of truth, improving the reliability of the application.
So, when does your business plan to migrate from CRUD to an event source architecture?
https://dzone.com/articles/why-do-you-need-to-move-from-crud-to-event-sourcin?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJhdWQiOiJhY2Nlc3NfcmVzb3VyY2UiLCJleHAiOjE2NDIxNDU1NzUsImciOiJLOEdoZGtjdlF2SHkzeDhwIiwiaWF0IjoxNjQyMTQ1Mjc1LCJ1c2VySWQiOjI0MzYwNzkwfQ.yHCE5wZnN1J6Gb4eKsvz-XrB82uZpWtFq3OmKmoHzbg