Month: January 2015

Command query responsibility segregation pattern with MongoDB, Redis and ElasticSearch

Posted on Updated on


In large scales data-centric enterprise application read write ratio is very high. In that case we want the fast read access with different search criteria from enterprise database. This is often a requirement for any large scales enterprise application.


In most of the cases for enterprise application data storage and retrieval is the fundamental thing. The Command Query Responsibility Segregation is very well known for this kind of requirement for multiple reasons.

Here this pattern is implemented using MongoDB as primary storage and Elastic Search and Redis as secondary storage. Following solution diagram will represent the same.

Every create, update or delete action for the domain object will go through following steps in Command Service:

1. Create, update or delete for a domain object happened on MongoDB as a primary storage.
2. Invalidate the Redis cache entry based on the primary key of the domain object.
3. Create, update or delete the Elastic Search index for the domain object.

Every query or read for domain object with search criteria will go through following stages in Query Service:

1. Try to get the primary keys from the elastic search index based on search criteria unless search is not based on a primary key itself.
2. Based on the received primary key from previous step try to get the domain object from  Redis cache.
3. If domain object is not available with cache, then get the domain object from MongoDB. (As retrieval using a primary key is always efficient with MongoDB or any other SQL providers)
4. Update the domain object into the Redis cache and return the result.

Using this pattern you can achieve better response time for all your read queries with some a write overhead and you don’t need to surprise and change your design after a performance testing.