The article is translated from the source
In this article, we will talk about a Design Pattern of Microservices architecture that is CQRS Design Pattern . We will use this pattern to design EC application with Microservice architecture.
The image above is an illustration of the CQRS Design Pattern
After reading this article, hopefully readers can draw for themselves the necessary knowledge to apply the CQRS Design Pattern to Microservices architecture.
CQRS Design Pattern
CQRS is one of the very important patterns when conducting retrieval / querying between microservices. CQRS can help us avoid complicated queries, CQRS stands for Command and Query Responsibility Segregation . Simply put it separates read and update operations for the DB.
With monolithic applications, most of us have only 1 DB, this DB takes care of both receiving complex queries and also taking on more CRUD tasks. However, as the application becomes more complex, the queries and CRUD operations will also become more complex, then it will be difficult to control the behavior of the system.
For example, with reading data, if our query is so complex that it is necessary to join 10 tables together , then the DB lock time will be longer and hence the delay in the query’s calculation will also be reduced. increase accordingly. Similar to the write operation to the DB, when performing CRUD operations we need complex validations that cause the processing time to increase, resulting in an increase in the DB lock time .
With CQRS we will use 2 different DBs for reading and writing with different “strategies” for them.
Moreover, we also need to consider the requirements of the system to come up with a suitable design, with ” read-incentive” applications we should design the system architecture so that it is highly centralized. go to reading DB.
Commands in CQRS will focus on updating data (e.g. adding items to cart, checkout order, …), so commands should be handled with message broker systems that provide a disparate way to handle commands. set.
Queries do not modify the data at all, it just returns JSON data with DTO objects.
To be able to completely separate Commands and Queries , we will divide the DB into 2 separate DBs. This way, if our application is a “readable” application, we will define custom schemas to optimize queries.
Materialized view pattern is a good example for reading DB implementation, this way we can avoid complicated JOINS operations and can map with predefined schemas specialized for query operation.
With this approach, we can completely use the NoSQL document database for reading and use RDB for writing
Instagram Database Architecture
Instagram uses 2 DB systems:
- RDB PostgreSQL
- NoSQL Cassandra
That means that Instagram uses Cassandra for read-incentive data . Use PostgreSQL for bio update.
How to synchronize DBs with CQRS ?
When splitting into 2 DBs, there is one problem that we need to pay attention to that is the synchronization of data between them.
This can be implemented using the Event-Driven Architecture application. With Event-Driven Architecture , when updating in main DB, we will publish an update event using message broker systems , this event will be digested by read DB, then sync data will be done.
However, another problem will arise here, which is the consistency issue . Since we implement async communication with message broker, the data will not be reflected immediately.
From there we come up with the principle of eventual consistency . Read DB will “regularly” synchronize data from the write database , it will take a certain amount of time to update the read DB “asynchronously”. We will discuss eventual consistency in the next sections.
At the beginning of the design, you can use the read database by replicating from the write database. This way we can use different read-only replicas by applying Materialized view pattern to increase query performance.
Moreover, because we split into 2 DBs, they can be scaled independently of each other depending on the requirements of the system.
Using Event-driven architecture to synchronize data requires us to know the Event sourcing pattern .
Architectural Design – CQRS, Event sourcing, Eventual Consistency, Maerilized View
I proceed with the architectural design of my EC application as follows:
With Ordering service, we will divide into 2 groups of DBs:
- Group 1: DB for writing with the nature of RDB.
- Group 2: DB for reading used for querying.
We will proceed to synchronize data between these two DB groups using the message broker system through the publish/subscribe pattern
And here is the tech stack I will be using for my EC application:
- SQL Server for RDB (writing DB)
- Cassandra for NoSQL DB (reading DB)
- Kafka for data synchronization 2 DBs
Translator’s words
Above is my translation, hope that readers can find useful information about CQRS as well as Event sourcing, see you in the next articles. Thank you.