CQRS pattern with ASP.NET CORE

CQRS is a command and query responsibility pattern that separates read and write operations into different models. Commands (Insert/update) operations will have a separate model. Queries (read) operations will have a separate model.  By separating them, it allows models to be more focused on the tasks that they are performing. 

Traditionally, commands will have a large model as it would map the model to the whole database table with some business logic validating the model before saving it the database. Whereas, on the other hand, queries will have a simple model, returning a dataset according to UI requirements. 

Traditional vs CQRS

In traditional applications, we use the same data model for read and write operations. It is good for simple CRUD applications but if you have a large complex application which has a large model. It get’s really difficult to manage it as every other change can cause issues in testing with additional bloated code. 

When we use CQRS, we can either have one database or we have can have two databases, one for commands and others for queries. If we create two databases then we have to keep them in sync. This is the additional work you have to do.

How to implement it?

You will see two folders, one for command and another for the query. Query folder has one model class and one handler. I am using a mediator pattern here, which I will explain in my other blog post.


In the following image, you can see the handler class receives the query model and makes a query to the database to get all users from the database.


In the following image, you can see the handler class receives the command model and makes a write operation to save the user in the database.


There are pros and cons to everything. Some of you may feel that implementing CQRS may add additional complexity to the project. In my opinion, It comes down to the use case of the project and how you use this pattern. I have also made a working demo app on GitHub with the CQRS pattern. 

Introduction to Microservices

Microservices is a new buzzword that is very popular nowadays. I have spoken to a few developers and every single one of them defines it differently. Some say ‘Microservices is just a pattern to break the large monolithic application into smaller monolithic applications’ while others describe it as ‘Microservices is just SOA (Services oriented architecture) done right’. In this blog, we will focus on microservices.

What is a Microservices?

It is an architectural style pattern that is used to develop large complex applications into small modular loosely coupled services that are small, independent, easily manageable, and deployable. In simple words, microservice helps you break a large application into smaller applications that enforce SRP (Single responsible principle).

Companies run into trouble when it gets too difficult to manage a large application and upgrade it.  Microservices is the answer and can help us break down complex large applications into small independent applications that communicate with each other using language-independent interfaces (APIs).

History of Microservices

Term microservice was coined in mid of 2011. 

The idea behind microservice is just good architecture principles. It has been around for a few decades. In the early 1980’s the first distribution technology Remote Procedure Calls (RPC) was introduce by Sun microsystems. 

Who is using it?

Companies like Netflix, Amazon, Uber, eBay, and Spotify have a microservice architecture that helps them serve resources with intensive requests in a scalable manner. Also, a lot of other companies are moving their monolithic products to microservice architecture.

There are many advantages and disadvantages of Microservices.


Modular and independent

Microservices are broken down into multiple service components by design, which are easily developed by small teams. Each of the service component is focused on a specific module, can be developed and deployed on docker independently. This helps new team members understand the functionality in less time. 

Decentralised and cross-functional

As Conway’s law states “The design of the software can tell us about the social fabric of the organisation and vice versa”. The small teams where every team member is responsible for each business function is ideal organisation for the development of microservices. From Architects, developers, QA engineers, product owner, analysts and DevOps – Each one is responsible for their own piece of microservices.

Highly Resilient

Microservices are better for fault isolation, if one service fails, other services will continue to work without impacting the whole system. If our monolithic application fails, everything that it’s accountable fails at the side of it. Therefore, microservices are highly resilient, needs orchestrator  and good cloud infrastructure for high availability.

Highly Scalable

Microservices are designed for scaling. Scaling allows applications to react to variable load by increasing and decreasing the number of instances of the services it’s using. Also, microservices are cost efficient as you scale the services based on their demand but in monolithic application you would have to scale the whole application irrespective of which service/function would be highly used.


Data Consistency

Microservices are designed to have their own data storage. This raises another question that how do we achieve the data consistency?  We use events driven approach and advanced messaging queue technology (Bus Service, RabbitMQ, etc). If a price of product is changed in the product microservice then we have to update the price in basket microservice. 


Microservice is a disturbed architectural design pattern. We have to make calls to different services to get the data. This leads to increase in round trips and more latency. However, you can minimise this by using API aggregate design to aggregate the data through API gateway.

High Complexity

Microservices are small and modular but when you have an application which consists of hundreds of microservices, calling each other. It becomes really complex.


Today, we have discussed what is a microservice, it’s advantages and disadvantages. I have also made a demo app for you to understand the whole concept. You can download the code and play around with it. In the next upcoming articles, I will explain a more hands-on approach and walk you through, how you can develop a microservice.