Adeptia Connect (AC) is an enterprise-class application that is designed for reliable, scalable, and secure operations in mission-critical use cases. Large organizations such as many Fortune 500 companies rely on Adeptia Connect to handle important data exchanges with external customers and partners as well as within internal systems and applications.

Adeptia Connect version 4.0 is a cloud-native application with microservice architecture. It uses Docker to containerize different microservices and uses Kubernetes for container orchestration and management. The application provides the following advantages:

1. It can run as a cloud-native application.
2. High scalability. Different microservices can be scaled as per need.
3. High availability.
4. Automated deployment and upgrade through CD pipeline.
5. Centralized monitoring and logging.

The Application Architecture diagram for Adeptia Connect is shown below.

Key components

External and inter-service communication 

External and internal communication in Adeptia Connect happens in the following manner.

• Synchronous external communication happens using REST protocol over https.
• Synchronous inter-service communication happens using REST protocol over https.
• Asynchronous inter-service communication happens using RabbitMQ Message broker.

Circuit breaker in Adeptia Connect environment

What and why

• Circuit breaker prevents the cascading effect of a malfunctioned microservice to other healthy microservices.
• Provides fault-tolerance capability to the application architecture.

Where it is applied

It rests and operates from the following three components of Adeptia Connect microservices architecture:

• Webapp Gateway
• API Gateway
• RabbitMQ

How it works

With the help of the circuit breaker the Webapp Gateway/API Gateway/RabbitMQ is able to make or break the communication with a failed microservice. To determine whether a microservice is up or not, the Webapp Gateway/API Gateway/RabbitMQ allows twenty consecutive requests to the microservice – if the response to all the twenty requests fails, it instructs the circuit breaker to open the circuit and thereby break the communication.

After the circuit remains open for sixty seconds, the Webapp Gateway/API Gateway/RabbitMQ once again allows a few requests (in this case, five) to check whether the faulty microservice has started responding or not. In such a condition the circuit breaker is said to be in half-open state.

• If the microservice responds to any of the five requests, the Webapp Gateway/API Gateway/RabbitMQ instructs the circuit breaker to close the circuit and thereby start the communication.
• If the microservice doesn’t respond to any of the five requests, the Webapp Gateway/API Gateway/RabbitMQ instructs the circuit breaker to keep the circuit open and thereby break the communication for the next sixty seconds.

This cycle continues until the microservice starts responding to the requests.

We need to mention this error message into the “troubleshooting runtime issues” document

Error 503 when sending request to a failed microservice is logged in application logs. The error message is...

Technology Stack