Hybrid microservice pattern to build the Orchestration Layer

What is Orchestration Layer?

The orchestration service layer introduces a parent level of abstraction that alleviates the need for other services to manage interaction details required to ensure that service operations are executed in a specific sequence. Within the orchestration service layer, process services compose other services that provide specific sets of functions, independent of the business rules and scenario-specific logic required to execute a process instance.

Why Orchestration?

Housing and Proptiger is a consumer-facing application where the application can expect millions of requests in a day, hence high availability and partition tolerance play an important role. Hence while designing the system we need to make the system fault-tolerant for high availability and partition tolerance. We can achieve the eventual consistency in the application at the database layer which should not be the concern for the end-user in real-time but downtime is.

How will it be achieved?

To proposed solution is the hybrid solution (orchestration + choreography pattern (reactive pattern)) to achieve high availability and partition tolerance which works best for the system where monolith and fewer micro-services are already built and it also leads to lower service migrations (application logic changes) while building the solution.

How does the choreography pattern come into play in the proposed solution?

• Decouples all the Orchestration services in the system
• Event Broker enables all the consumers to act independently in parallel
• Event Broker can be scaled up or scale down depending on the needs
• No re-deployment is required for Event Broker in case any service or any API contract changes.
• High availability of the system, in failure case of any service its replica can serve the request. i. Eg: If Event Broker goes down, the replicant broker can act as master keep all the requests in the queue

How does the orchestration pattern come into play in the proposed solution? Well, the orchestrator ( sub-grouping of related services) helps in routing the request to correct individual services.

Stateless orchestrators will help in serving the request with higher availability if implemented with better load balancing algorithms like Weighted Response Time. We can keep one orchestrator with a higher configuration and the other with a lower configuration to balance the load. Multiple stateless orchestrators can act as aggregator services by using the right communication channel.

Event Broker can make the system more real-time if implemented with message pattern along with “at least one” delivery configuration for the queue. In this way, even if one orchestrator fails to respond our client request will not be wasted instead, it will be served by the other orchestrator making the request drop count very less.

Swagger Service can also be used. Its main role would be to keep track of all the Schema/API documentation from each service or orchestrator which are going through the Choreography layer. It can be hosted as a separate entity as a swagger server which any client can look into and make the request as per the need.

As we can see from the architecture that the system will need more throughput along in terms of I/O operations as compared to the computational intensive operation we will use Node.js is one of the de-facto languages to build these kinds of architecture. Irrespective of the orchestration layer, individual services can be built in any platform and expose their APIs which will be consumed by the relevant orchestrator.

Each orchestrator and event broker will be a Dockerized solution, making it easy for orchestration tools like Kubernetes to scale it up and down as single PODs. Hence any new feature, any new tech stack will not be impacting the experience for the end-user while making the system highly available and partition tolerant at the same time.

Orchestrators

Based on the request types and collection of APIs, we can group the services. For example :

• Orchestrator 1
• Orchestrator 2

Each orchestrator is based on a hybrid micro-service template which allows it to receive and send messages to and from API gateway as well as to other orchestrators. Here are a few key features of the orchestrator template that we have created -

• Uses TCP to send and receive messages to different orchestrators
• Uses GraphQL for its strong feature set and more importantly for delivering the exact data the client needs rather than delivering complete data set. All APIs will be modeled in GraphQL with their own independent resolvers.
• Uses Kafka as a message broker system for publishing messages and retrying failed API events. It makes the system more robust and reliable.