Microservice Architecture

Pattern: Command Query Responsibility Segregation (CQRS)

Context

You have applied the Microservices architecture pattern and the Database per service pattern. As a result, it is no longer straightforward to implement queries that join data from multiple services. Also, if you have applied the Event sourcing pattern then the data is no longer easily queried.

Problem

How to implement queries in a microservice architecture?

Solution

Split the application into two parts: the command-side and the query-side. The command-side handles create, update, and delete requests and emits events when data changes. The query-side handles queries by executing them against one or more materialized views that are kept up to date by subscribing to the stream of events emitted when data changes.

Examples

Customers and Orders is an example of an application that is built using Event Sourcing and CQRS. The application is written in Java, and uses Spring Boot. It is built using Eventuate, which is an application platform based on event sourcing and CQRS.

This application maintains a CQRS view in MongoDB. Each document contains information about a customer and their orders. The view is updated by subscribing to customer and order events:

@EventSubscriber(id = "orderHistoryWorkflow")
public class OrderHistoryViewWorkflow {

  private OrderHistoryViewService orderHistoryViewService;

  @Autowired
  public OrderHistoryViewWorkflow(OrderHistoryViewService orderHistoryViewService) {
    this.orderHistoryViewService = orderHistoryViewService;
  }

  @EventHandlerMethod
  public void createCustomer(DispatchedEvent<CustomerCreatedEvent> de) {
    String customerId = de.getEntityId();
    orderHistoryViewService.createCustomer(customerId, de.getEvent().getName(),
            de.getEvent().getCreditLimit());
  }

  @EventHandlerMethod
  public void createOrder(DispatchedEvent<OrderCreatedEvent> de) {
    String customerId = de.getEvent().getCustomerId();
    String orderId = de.getEntityId();
    Money orderTotal = de.getEvent().getOrderTotal();
    orderHistoryViewService.addOrder(customerId, orderId, orderTotal);
  }

  @EventHandlerMethod
  public void orderApproved(DispatchedEvent<OrderApprovedEvent> de) {
    String customerId = de.getEvent().getCustomerId();
    String orderId = de.getEntityId();
    orderHistoryViewService.approveOrder(customerId, orderId);  }

  @EventHandlerMethod
  public void orderRejected(DispatchedEvent<OrderRejectedEvent> de) {
    String customerId = de.getEvent().getCustomerId();
    String orderId = de.getEntityId();
    orderHistoryViewService.rejectOrder(customerId, orderId);
  }

OrderHistoryViewService uses Spring Data for MongoDB to update MongoDB.

There are several example applications that illustrate how to use event sourcing.

Resulting context

This pattern has the following benefits:

• Necessary in an event sourced architecture
• Improved separation of concerns = simpler command and query models
• Supports multiple denormalized views that are scalable and performant

This pattern has the following drawbacks:

• Increased complexity
• Potential code duplication
• Replication lag/eventually consistent views

Related patterns

• The Database per Service pattern creates the need for this pattern
• The API Composition pattern is an alternative solution
• The Saga pattern pattern generates the event stream
• The Event sourcing is often used with CQRS

See also

• Eventuate, which is a platform for developing applications with Event Sourcing and CQRS
• Articles about event sourcing and CQRS