Digitization drives banks to offer their service in various open platforms through the banking API which is designed in Microservices architecture. This article shares key architectural considerations of Microservices.
Microservices is an architectural style for designing distributed and scalable API in containerized environments. The common use cases are order placement, information query and data streaming.
The API of these use cases are autonomy, loosely coupled and handling transactions in a collaborative approach.
Here are five considerations for the architectural design of Microservices API.
1. Dynamic Configuration
2. Service Discovery
3. Load Balancing
4. Circuit Breaker
5. Distributed Tracing
1. Dynamic Configuration
Microservices API supports multiple instances on different environments. Each environment may have different configurations, such as IP address, CPU or memory.
Hence the design should consider a centralized configuration service that provides different configurations for different API instances.
In addition, the design should also consider the auto refresh of the configuration without restarting the API instance. One of the approaches is to refresh the configuration from the service periodically.
Alternatively, we could make use of a message broker to refresh API configuration on a real time basis. When there is a configuration change, the configuration service could send the new configuration to the message broker which then pushes it to the API through a message queue.
2. Service Discovery
Apart from calling the Microservices API from the external consumers, Microservices API may also collaborate to serve the requests.
Therefore, the design should consider API discovery service which publishes an online and real time directory of all the currently online API and their invocation details.
Under the container environment, the API invocation could be changed dynamically, for instance, the container may assign a different IP to the API instance every time it is started.
To maintain real time information on the discovery service, each API could send a registration message to the service when it is started. Then periodically send a heartbeat signal to the discovery service. API without a heartbeat signal for a certain period should be considered offline and removed from the list.
3. Load Balancing
Since Microservices API is highly scalable, several API instances could be running concurrently. The design should consider load balancing that distributes incoming requests across the running API instances.
There are two load balancing approaches, server side and client side.
Server side approach has hardware or software servers sitting between the API and its consumers. All incoming requests will be routed to the load balancer which will redirect the requests to the API based on its load balancing strategy.
The advantage of the server side approach is the independent implementation from the API and consumers. The disadvantage is the high network latency.
Client side approach has the load balancing module embedded in the API clients. All API instance information is contained in the memory space of the API client so it can call the API instance directly.
The advantage of the client side load balancing is low network latency. The disadvantage is the dependency on API implementation.
The common use case is to use server side approach for external API consumers, and use client side approach for inter-API collaboration.
4. Circuit Breaker
Since Microservices API will collaborate for client requests, failure of one API will cause cascading failure and make the client requests unresponsive.
The Microservices design should consider a circuit breaker that protects the API against cascading failure.
Circuit breaker is a software device that detects the API failure based on the predefined conditions and thresholds. In the situation of API failure, it will apply the recovery or fallback approach, such as calling an alternative API or returning the cached values.
There are three states of circuit breaker;
Close - this state means all API are normal and circuit breaker will not intervene the API calling process.
Open - this state means there is an API failure, circuit breaker will apply recovery or fallback approach.
Half-Open - After a period in the Open state, the circuit breaker will change itself to half-open state automatically. Under this state, the circuit breaker will call the failed API again. If the call is successful, it will change its state to Close, otherwise it will change its state to Open.
5. Distributed Tracing
The distributed nature of Microservice API makes the execution tracing and debugging to be very difficult. Hence the design of Microservices API should consider a distributed tracing mechanism.
We could apply the audit trail service that provides a unique identifier to every call from API consumers. The unique identifier will be passed along to every inter-API call and written into the log entries.
An audit trail analysis tool will retrieve log entries from different API instances, then consolidate, analyse and reorganise the log based on the unique identifiers and time stamps to determine the execution chain and chronological sequence of the API events.
Thank you for reading this article. For the details of Architectural Considerations of Microservices, please contact us. If you want to receive more information about finance and technology, please follow our LinkedIn or subscribe to the “FinTech Insights”.
Axisoft is a Top-Notch Financial Technology Provider in Hong Kong, Singapore and China. Since 1998, we have been helping financial institutions implement global banking solutions.
Comments