What pattern is considered CQRS?

Does it matter?

Photo by Insung Yoon on Unsplash

This week, in our study group, there is an interesting question.

If our service use MongoDB as the primary database and leverage ElasticSearch to benefit searching. Each request is in, our service is responsible for a dual write to update both MongoDB and ElasticSearch. Is this implementation considered CQRS?

In fact, this implementation is indeed generating a read model for searching and a write model for domain operations. If there is any search request, we can build a search layer or a search service for that.

This looks like CQRS, doesn’t it?

In my opinion, such an implementation is not CQRS.

There are two core concepts about CQRS.

1. event sourcing
2. responsibility segregation

Let’s see their actual meaning.

Event sourcing

Event sourcing is the most important concept for CQRS. When we have a new feature requirement, we can leverage the existed events and replay to generate a new read model so that we don’t need to modify the original code base.

In other words, we can easily fulfill any query requirement without impact the production functionality.