CQRS (Command Query Responsibility Segregation) STRUCTURE ? (PART 2)

Thu Ngan Pham — Tue, 27 May 2025 13:41:36 +0000

Below are the CRUD operations surrounding the Post module, totaling up to 282 lines of code. This can lead to several issues such as violations of the SRP principle in SOLID, race conditions, inconsistent states, lock conflicts, and so on.

These issues can be addressed by reorganizing the code — clearly separating services, using transactions, applying Optimistic/Pessimistic Locking, and offloading auxiliary logic to Events or Queues.

Additionally, you might consider adopting the CQRS architecture, a pattern that clearly separates read and write operations. When combined with principles such as event sourcing, proper locking, and asynchronous processing, CQRS can help the system become more scalable, manageable, and less prone to complex errors.

Note: This is just a sample source code for Post, following a flat comment structure similar to Google Maps

With CQRS, the read and write flows are separated, allowing each component to have a single, focused responsibility. Each CommandHandler is responsible solely for performing actions (create, update, delete), while each QueryHandler is only concerned with data retrieval.

These handlers typically contain only a single function for processing, making the codebase clean and elegant, avoiding the "God service" anti-pattern. It also improves performance, as the read flow can use a dedicated database, isolated from the complex operations in the write flow.

By separating read and write logic, it's also easier to:

Apply transactions to CommandHandlers
Use locking strategies (optimistic/pessimistic) in writes to avoid conflicts
Isolate side effects of write actions, reducing the risk of affecting the overall system state

As a result, the codebase becomes easier to scale and maintain.

Pattern CQRS (Command Query Responsibility Segregation) combined with Event Sourcing (Part 1)

Thu Ngan Pham — Wed, 02 Apr 2025 15:04:18 +0000

CQRS Pattern (Command Query Responsibility Segregation) Combined with Event Sourcing

In traditional architectures, applications interact with the database using CRUD operations for both reading and writing. However, as applications scale and the number of requests increases, this approach can lead to performance bottlenecks. Designing the system with a single data model can result in several issues:

Lock Contention

Before diving into CQRS, let’s discuss "resource contention." Consider the following example:
A user clicks the BOOK button, triggering two API calls:

GET /flights/seats returns the number of available seats.

POST /flights/book reserves a seat.

If two users attempt to book the same seat (e.g., seat A1) simultaneously, both requests might retrieve outdated data and successfully reserve the same seat. To prevent this, the system must implement locking mechanisms to maintain data integrity. However, locking slows down the system because requests must wait for one another to complete before proceeding.

Data Mismatch

Data mismatch occurs when the structure of data used for reading and writing is not well aligned, leading to performance degradation.

Write operations:

When a user creates or updates a post, the system must store all related data, such as title, content, tags, likes, authorInfo, and comments. However, some fields, like authorInfo, may not be necessary for most read operations.

Read operations:

If a user only wants to see a list of posts (e.g., displaying only the title and number of likes), querying unnecessary fields like authorInfo and comments increases the data load.

To address this, developers may use data references, caching, or document duplication, but these approaches complicate data integrity maintenance.

Performance Problems

A traditional architecture that relies on a single data model for both reading and writing can face several performance issues:
Database Overload: Handling simultaneous read and write requests can strain the database.

Query Complexity: Retrieving product details and comments in an e-commerce system may introduce high query latency.

Scalability Issues: During peak traffic, simultaneous read and write operations can cause bottlenecks.

Lack of Optimization: Read and write operations can interfere with each other, reducing overall system performance.

Security Challenges

Managing security becomes more complex when entities handle both read and write operations. Overlapping responsibilities may expose sensitive data in unintended scenarios.

Although each of the issues above has individual solutions, CQRS simplifies the overall architecture by separating read and write operations. This separation enhances performance and makes it easier to handle complex scenarios. By implementing improvements such as client-side validation, optimized server logic, and asynchronous processing, developers can optimize both read and write operations, reduce errors, and provide a better user experience.

In the next article, I will discuss the architecture and implementation of CQRS combined with Event Sourcing.