Lagom Zero Hour: CQRS Concepts

CQRS stands for Command Query Responsibility Segregation.

The approach that individuals use for interacting with a data system is to treat it as a CRUD datastore. By this, I mean that we have a mental model of some record structure. We think about producing new records, scanning records, updating existing records, and deleting records once we’re finished. Within the simplest case, our interactions are all regarding storing and retrieving these records.

You can't really enjoy the advantages of CQRS without considering the user interface. Creating it captures the user purpose expressly, taking into consideration that client-side validation and command structures could also be somewhat balanced.

Traditional Approach

As this happens, we start to visualize multiple representations of knowledge. Once you move with the data, you use various displays of this information, all of which may be a totally different representation. Developers generally build their own abstract models that they use to control the core components of the model. If you are employing a domain model, then this can typically be the complex illustration of the domain. You also usually create persistent storage as on the point of the abstract model.

Problem With the CRUD Approach

This structure of multiple layers of representation will get quite complicated, however, what one can do is still resolve it right down to one conceptual representation that acts as a conceptual integration point between all the displays.

As our needs become more advanced, we have a tendency to steadily move away from that model. We have a tendency to look at the knowledge in a completely different way than the way we record, maybe collapsing multiple records into one or forming virtual records by combining info. In the update, we have a tendency to notice validation rules that enable combinations of knowledge to be held onto or even infer knowledge to be held onto, which is completely different from what we provided.

CQRS Approach

By separating models, we commonly mean totally different object models, most likely running in several logical processes, and maybe on separate hardware. An online example would be to see a user viewing an internet page that is executed using the query model. If they initiate a change, then the modification is routed to the separate command model for processing, and the resulting change is communicated to the query model to render the updated state.

Benefits of CQRS

• CQRS permits you to separate the load from reads and writes, permitting you to scale each independently. If your application sees a gain inequality between reads and writes, this is often very handy. Even without that, you’ll apply totally different improvement methods to the two sides.
• Using CQRS on a domain that does not match, it’ll add complexity, therefore reducing productivity and increasing risk.

Write-Side vs. Read-Side in CQRS

A benefit of this pattern is the separation of concerns between the write and the read side. Then the entities can focus on updating commands, and the read-side can be optimized for various queries and reporting jobs. A single conceptual model that tries to encapsulate both read and write operations may do neither well.
It is important to realize that the write side has completely different needs from the read side, and separating those concerns makes it possible to offer the best experience for the write and read sides independently.

This separation is also great for scalability since the read side can be scaled out to many nodes independently of the write side, and it's often on the read side that you need massive scalability.

A consequence of separating the read-side is that it is eventually consistent, i.e. it may take a few seconds until an update to the write-side is visible on the read side.

Caution With CQRS

Not a silver bullet, every case doesn’t fit with this CQRS approach.

Many systems do fit a CRUD mental model, and they should be wiped out of that style. CQRS may be an important mental leap for all concerned and therefore should not be tackled unless the profit is definitely worth the jump. CQRS should only be used on specific portions of a system and not the system as a whole.

Lagom is an open-source microservice framework built on top of the Akka and Play frameworks. Lagom Persistence makes use of Event Sourcing and CQRS to help achieve decoupled architecture.

You can find real-life examples of how Lagom handles Event Sourcing and CQRS in the following blogs:

• Data Persistence in Lagom
• Persistent Read Side in Lagom