Microservice Architecture in .NET

In my previous blog we already discussed Microservice Architecture using Java but today we are going to develop and understand how we can leverage the Microservice architecture using .NET core API, and what all tools we can use to make it Resilience, observability, Fault-tolerance, Monitoring, and Rate-limiting and all other components which are necessary for any Microservice driven architecture.   

Before we move forward let's review some PROS and CONS of having Microservice and Monolithic architecture.

To start with let's build an example, where we are going to create a Catalog and Inventory APIs and build our Microservice architecture around it. So the big question comes when to use Microservices?

• It's fine to start with a monolith and then move to Microservices 
• And We should start looking at Microservice when:
• The code base size is more than what a small team can maintain
• A team can't move fast anymore
• Build because too slow due to large code base
• Time to market is compromised due to infrequent deployments and long testing times.
• It's all about team autonomy.

In our previous Microservice architecture in JAVA, we build Microservice which communicates synchronously but today we are going to build an asynchronous Microservice, and will also understand its benefits.

Synchronous Communication 

• The client sends a request and waits for a response from the service which is exactly happening in our Mircorservice example in JAVA
• The client cannot process without the response.
• The client thread may use blocking or non-blocking callbacks.
• REST+HTTP protocol is the traditional approach
• Partial failures will happen.
• In a distributed system whenever a service makes a synchronous request to another service, there is a risk of partial failure.
• So, We must design our services to be resilient 
• Timeouts, for more response experience and to ensure resources are never tied up 
• Implement a Circuit breaker pattern to prevent our service from reaching resource exhaustion 

Asynchronous Communication

• The client does not wait for a response in a timely manner
• There might be no response at all
• Usually involves the use of a lightweight message broker
• Message broker has high availability 
• Messages are sent to the broker and could be received by a single receiver or multiple receivers 

In the Asynchronous Microservice, which I build. 

• For resilience and transient-fault handling capabilities, Retry, and Circuit Breaker.  I have used Polly.NET libraries.
• For API Gateway, Caching, and Rate Limiting, I have used Ocelot .NET libraries. 
• For Monitoring, I have used Prometheus and Grafana.
• RabbitMQ is used for messaging.
• MongoDB is used to store the data.

The Code is available on GitHub. 

Happy coding and keep sharing!!