Microservice is application architectural style to build application which best suits for large complex system. Microservice based application contains loosely coupled small independent deployable projects.

Components of Microservice

1) Service Fabric

  • Azure Service Fabric is a Microsoft’s microservice platform and includes container orchestration as well as developer programming models to build highly scalable microservice applications.
  • We can deploy service fabric platform to Azure, AWS or on premise (on Windows or Linux machine)
  • As of now we can deploy stateless containerized application to service fabric.
  • Service fabric platform provides features like Naming Service (Service Discovery and Service Registry), Monitoring, Logging, fault tolerance capability etc.
  • We can add host/virtual machines from different geographic and network location to service fabric cluster by ‘Powershell’ cli or through service fabric manifest file.
  • Service fabric then automatically balance the nodes, if any node goes down it will up other node and host required application instance on the newly added node.

2) Service programming model

  • Stateless Services

    • When we need to persist data to external storage, we will build stateless service.
    • Most of the time we need to store data in external storage (MS SQL, NoSQL storage) so stateless services use most of the time.
    • We can containerize this type of services, as of now we can host this type of service to ‘Docker’ in service fabric.
  • Stateful Service

    • When we need to persist data to service itself, in that case we can build Stateful service.
    • We can reduce latency between business logic and data.
    • Stateful services stores through reliable collections to node itself (In main memory, hard disk)
    • Data will be stored across different partitions to scale and replicate to several nodes to make sure data availability 24X7
    • As of now we cannot host service to container but in future, this feature might be included

3) Communication between services

  • Client application will communicate with service through Rest APIs (HTTP Request/Response) protocol. This type of communication is synchronous in nature, caller will wait till response get back.
  • We can follow different technique to communicate between services (communication between services within cluster)
  • We can communicate between services asynchronously (Using Event Bus – (Service can Publish – Subscribe to specific event by other service)) wherever possible in case somehow we will not able to communicate asynchronously then we will synchronously communicate between services over Rest APIs.
  • So that way we can reduce the tight coupling between the system and in case if we need to implement other behavior for specific event then in that case service just need to subscribe that specific event, so that’s the way we can choreograph the system and we can make the system more loosely coupled
  • We can use Azure service bus to perform asynchronous message based communication between services there are other tools also available i.e. RabbitMQ, ActiveMQ etc.

4) Event bus

  • Event bus allowed the publish-subscribe style of communication between services.
  • Using event bus we can establish asynchronous style of communication between services.
  • Each service can subscribe particular event and whenever any event occurred specified method will be invoked in service.
  • For instance, if ‘Service A’ publish event named ‘OrderCreated’ and this event is subscribed by ‘Service B’ then whenever ‘OrderCreated’ event published by ‘Service A’ this event will be pushed to queue and later it will be processed by ‘Service B’.
  • We can further extend ‘Event Bus’ to implement ‘Event Sourcing’ and ‘CQRS (Command Query Responsibility segregation)’ pattern.
  • Event bus is enabled us to implement asynchronous messaging pattern thus system can be choreographed properly and we can reduce coupling between service.
  • Azure Service Bus can be used to implement this

5) Circuit Breaker


  • Many times due to the fault of downstream service the caller system might get collapsed due to all resource exhausted, due to this we might end up whole system down because of cascade fall down, to prevent this we use Circuit Breaker pattern which works like a switch between caller service and downstream service. if downstream service get time out or return any exception occurred (i.e. HTTP 5XX errors) then switch will be set off
  • To apply Circuit breaker pattern we use POLLY (http://thepollyproject.org) library.
  • Polly provides features like Circuit Breaker, Bulkhead isolation.

6) Load Balancer

  • Load balancer will route traffic to different nodes to distribute traffics over available nodes.
  • Load balancer first query to Service Registry (Naming Service) to get details of available online nodes. So that it can route traffic to nodes.
  • We can use Azure Load Balancer service to implement this.

7) Service Discovery and Service Registry (Naming Service)

  • This both techniques are responsible to find the physical location of particular service in cluster.
  • Whenever any service up in cluster it will register its IP address with service registry. after particular timespan heartbeat signal will be sent to know whether service is still alive or not.
  • Whenever any service request come to network it will first send request to service registry to find out location of service, this mechanism implemented on top of load balancer. once load balancer get physical location of that node it will redirect request to that specific node.
  • If we use Service Fabric as our microservice platform, then Service Discovery and Service Registry mechanism will be built in implemented (Naming Service in Service Fabric)

8) API Gateway

  • API Gateway consist of several small projects which act like an aggregator or a proxy to inner service layer.
  • API Gateway acts like entry point to the application.
  • There are several benefits of API Gateways like, we can implement Authorization, HTTPS termination, we can aggregate response from various service and send back it to caller so that they do not need to call multiple service, this will very helpful for mobile clients.
  • We can use API gateway as back end for front end. We do have separate gateway for different type of consumer i.e. Web client, Mobile client etc.

9) Authentication and Authorization

  • We can use ‘IdentityServer4’ or ‘auth0’ or ‘octa’ for authentication and authorization purpose.
  • IdentityServer4 is community driven project which offers features like Single Sign on, Refresh token, token based security, one can revoke generated token, Support External Identity provider (Google, Facebook), Admin UI (in beta version) for user management etc.
  • Built on top of .NET Core so we can deploy it on both Windows or Linux machine.

Advantage of having Microservice based application

  • Each service is relatively small, so it is easier to maintain code and reduced build time
  • We can add more feature in less time compare to monolith application
  • Each service can be deployed independently, we can do releases more aggressively
  • Easy to scale (Horizontal scaling)
  • Different technology stack can be used in different services


  • Limited tooling support available to deal with complexity in microservice based application
  • Difficult to create testing environment
  • Memory/bandwidth consumption will be increased
  • There is no support for transaction
  • One should have domain knowledge to break functionality into individual service
  • Must have deal with problems of distributed system
  • Performance might be reduced
  • Not suitable for small application