CQRS pattern in microservices

CQRS pattern in microservices

CQRS (Command Query Responsibility Segregation) is a design pattern that suggests separating read and write operations into separate models to improve scalability, performance, and maintainability of the system. In a microservices architecture, CQRS can be applied to separate the command side (write operations) from the query side (read operations) of the system.

In this case, the Command side would handle the creation, updating, and deletion of products. This would involve services that allow users to add products to the system, update product details, and delete products from the system.

On the other hand, the Query side would be responsible for handling user requests for product information. This would involve services that allow users to search for products based on various criteria, such as name, category, price range, etc. The Query side would be optimized for fast read operations.

DDD, event-sourcing and CQRS

High level design of CQRS pattern

DDD

  • Command - imperative form
    - either fulfill the request
    - rejected
    - Failed
    - Successed
    - Finished
    - Changed to "Fact"
    e.g.
    Command Event (Fact or Systems reaction to your commands)
    Open game Game Opened
    Make guess Guess Made
    Succeeded
    Failed
    Completed
  • Information (state)
    - where all commands and all the events can refer to
    - Commands and events which can affect the state and state it self they are combined into the larger picture
    - know as Aggregate
    e.g.
    • level
    • isCompleted

Event sourcing

  • Design pattern about persisting data
  • Don't save current state of the system but steps that led to the current state
  • e.g. git, or bank account statement
  • You can replay all the events in sequence

CQRS (Command Query Responsibility Seggregation)

  • CQS on the application level
  • CQS - Command Query Separation
  • Command - Write
  • Query - Read
  • Bounded Context (Ubiquitious language)
    • Language barrier
    • Language has to be unique
    • e.g. NeverCompletedGame
  • CAP theory
    • Consistency
    • Availability
    • Partition

Read more