By: Dr. Shailesh Kumar Shivakumar, Solution Architect

In many complex enterprise application scenarios, the application’s query part (consisting of data reads) and the command part (consisting of data updates) use the same database instance, impacting the overall application performance. This strains the database, slows down read operations, and has a detrimental effect on user experience. In this blog, I briefly explain the key use cases of a pattern to address the problem.

Command Query Responsibility Segregation (CQRS)

Certain digital marketing platforms have primary data render (data read) scenarios with only a few scenarios for data updates. In such cases, the application performance is impacted when both the data read and data write happen on the same database instance. This strains the database instance significantly and leads to slower results which impact user experience. We can optimize the overall application performance by decoupling the data read operation from the data write operation.

The CQRS pattern provides a neat way to implement this strategy. CQRS provides different pathways for the query part and command part so that they can be scaled independently. This serves to improve performance and accelerate read/write operations.

CQRS + event sourcing

We can combine the CQRS with an event sourcing pattern to implement a full-fledged optimal solution. We can define the state of an entity as an immutable sequence of events. By replaying the events, we can construct the entity’s state. We can publish the event states to a queue so that subscribers can listen to those events.

I have depicted the implementation of CQRS along with event sourcing in Figure 1 using AWS.

Figure 1: CQRS with event sourcing

The API clients such as web pages or mobile apps initiate the request through the AWS API gateway. When the request reaches the microservices, they use different processing pipelines for data read and data write operations. We can use AWS Fargate with AWS ECS to implement the microservices.

The application loads the data from the read replica into the caching system (such as AWS Elasticache). All the data reads are processed from AWS Elasticache for optimal performance.

The data write operations are pushed to the AWS SNS topic. We can specify the details such as operation type (insert/update/delete) along with the updated details. We can use the message sequence number to ensure the correct sequence of the messages. The microservices subscribed to the SNS topic will pick up the message and use a data service to update the master database (AWS RDS). If the operation fails, it is added to the AWS SQS which acts as a dead-letter queue. The AWS Lambda is triggered when the message arrives in the SQS queue and adds the failed operation back to the SNS topic.

Using this method, we decouple read operations from write operations providing independent scalability.

Use cases for CQRS pattern

Given below are the use cases for the CQRS pattern:

• Digital marketing applications that are read-heavy and need high performance for data read operations.
• Collaboration portals that have complex data write operations that need independent scalability.
• Applications that have complex workflows and business processing requirements with strict performance SLA and complex business logic.

Therefore, implementing the CQRS pattern can accelerate data read/write operations and optimize application performance in several scenarios. It also opens the door to greater scalability and ultimately ensures a better user experience.