Application architecture

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.1 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.
6. Tenant boundary based on Partner and Process flows.

The Application Architecture diagram for Adeptia Connect is shown below.

Key components

External communication 

Adeptia Connect has two ways to communicate over the public internet using REST over https and SOAP (Refer to blue arrows in the diagram).

Browser client : User will access Adeptia Connect using web interface in browser. Any user request from this UI is routed via webapp-gateway to portal microservice and web-runner microservice. This is a synchronous communication using REST over https.

API Client: A user can access API published on Adeptia Connect using API client. The request is routed via api-gateway to rest-api or soap-api microservice depending on whether the API uses REST (HTTPS) or SOAP protocol.

Inter-service communication

The inter-service communication happens in two ways – Synchronous using REST over https (Refer to green arrows in the diagram) and Asynchronous using RabbitMQ Message broker.

1. Synchronous using REST over https (Refer to green arrows in the diagram): There are two types of requests where this is being used.
   1. webrunner micro-service: All the calls for GUI actions go to the webrunner microservice, and the webrunner in turn initiates the inter-service communication with the other microservice via webapp-gateway.
   2. API microservice: rest-api and soap-api microservices call runtime microservice to execute the process flow published as API or Transaction published as webhook.
2. Asynchronous way using RabbitMQ Message broker: There are three types of communication that happen using this method (Refer to the orange arrows in the diagram).
   1. Queue Transaction and Trigger Transaction: As listener and event microservices find new data to process, they create a Job in RabbitMQ. Runtime service listens to this queue, and triggers the execution of the Process Flow or Transaction.
   2. Maintenance Tasks: Any update in the application settings raises an event in the dedicated maintenance queue in RabbitMQ. All the microservices are the consumers of this maintenance queue and get notified when the application setting is updated. This ensures automatic reloading of the application settings in the corresponding microservice.

Persistence

There are two types of data in Adeptia Connect that require persistence (Refer to the dotted arrows in the diagram).

1. Data in shared volume using PV/PVC
1. Metadata files and dependencies.
2. Repository files generated at runtime and their archive.
2. Data stored in the database
   1. Backend Database – Stores all metadata related to users, transactions, configurations, partners.
   2. Log Database – Stores all runtime execution details, log information, and audit trails.

Scalability

Individual microservice in AC 4.0 are scalable and can scale up or down based on their respective scalability criteria and threshold.

1. Runtime microservice is scalable based on number of the messages in the RabbitMQ queue. If the number of messages in the queue exceeds the threshold (default 5), the autoscaler spins up a new runtime pod. This threshold value can be configured in the values.yaml by changing the value for the environment variable MAX_QUEUE.

2. All other Microservices are scalable based on the CPU and Memory utilization percentage. Autoscaler spins up a new pod if the CPU or Memory utilization of the pod increases beyond the threshold value. This threshold value can be configured in values.yaml by changing the value for the environment variables targetCPUUtilizationPercentage and targetMemoryUtilizationPercentage under autoscaling section of the microservice.

   The listener and license microservices have only one replica set (single instance) each.

3. Dependency Scaling
   

   An application that is architected, built, and run to be perfectly scalable in every way still faces scalability challenges if its dependencies cannot scale with it. Ensuring that all dependencies will scale with a microservice’s expected growth is essential for building production-ready services.

   As you scale microservices in the Adeptia application, you need to ensure that the underlying database is scalable and performant. With an increase in the number of microservices and the incoming requests, the interaction with the database increases. Therefore, the database shall be able to handle the surge in the requests by allowing more concurrent active connections and be able to return the results promptly.

   Similarly, with an increase in the number of microservices, the application interaction with the shared volume provisioned in the Kubernetes cluster through PV/PVC increases. As you scale the microservices in the Adeptia application, you need to ensure that the shared volume(PV/PVC) is sized to a correct value and configured for high performance for I/O intensive workloads.

Fault tolerance 

Fault tolerance is the capability that enables the application to continue operating properly in the event of the failure of some of its components. Adeptia Connect application provides fault tolerance capability using Circuit Breaker and Timeout.

Timeout

Any REST Https call from one service to another via gateway implements Timeout mechanism. If it takes longer than the configured timeout to respond to a REST Https call, the call is treated as failed. 

Circuit Breaker

Circuit Breaker prevents the cascading effect of a malfunctioned microservice to other healthy microservices and provides fault-tolerance capability to the application architecture.

In AC4, the circuit breaking is implemented using the following three components of the application.

• webapp-gateway
• api-gateway
• rabbitmq
  
  

How Circuit Breaker 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 20 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 60 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.