Microservices Architectural Patterns Part-1

Below are the topics we are going to cover in this Microservices Architectural Patterns series

Part 1 Microservices Introduction, microservice template, communication, Service Registry and Discovery

Part 2 Microservice Database patterns and Orchestrator vs choreography

Part 3 Fault tolerance and monitoring

What are microservices ?

Microservices — also known as the microservice architecture — is an architectural style that structures an application as a collection of services that are

  • Highly maintainable and testable
  • Loosely coupled
  • Independently deployable
  • Parallel development and also promotes the scalability

Microservices are the true example for the SAR ( Single responsibility principle )

Key terms in a microservice architecture

Microservice template : Template contains the project structure along with cross-cutting concerns like Logging, Metrics and connection setup like DB or a messaging brokers

Just a note, it is not necessary to have same project structure or same tech stack. each team can choose their own stack depends upon the requirement


How these services are communicate with each other?

  1. RPI — Remote procedure invocation
  • Using Rest API, gRPC, Apache Thrift microservices can communicate with each other

2. Asynchronous Message-Based Communication — The communication between micro services will happen through a Message bus This commination can be achieved through any
message brokers technologies like RabbitMQ or Kafka

3. Domain-Specific Protocols: Also called as a custom protocol there are numerous domain-specific protocols including:
Email protocols such as SMTP and IMAP Media streaming protocols such as RTMP, HLS, and HDS

Registry :

Before a microservice sends a request to other microservice, it must be aware of the available instances and network location. Ideally, the number of instances of each microservice may be scaled dynamically to adjust the changes in load.

On each service startup, shutdown and on regular intervals microservice registry keeps track of this information.

If one service wants to communicate another, the route will be decided by the registry dynamically. So application code or in-app database no need to maintain other services network location or app id’s

How it works


it is classified into two types

Client-side discovery : In Client-side discovery Microservice will directly query the service registry to get another service network location and available instances etc.

Server-side discovery: Here, the microservice queries the Load-balancer to get the details of another service. Internally load-balancer call’s the registry to get the corresponding information

software architect, algo trader, machine learning enthusiast