Microservice Request Merging to Reduce Network Latency
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Micro-service architectures experience increased network latency and overhead due to the large number of remote calls required when transforming from monolithic to micro-service architecture, leading to higher costs compared to traditional monolithic architectures.
Innovation Solution
A computer-implemented method that splits initial requests into multiple requests based on business logic, acquires mapping information to identify candidate requests for merging, and sends merged requests to capable nodes, reducing interactions between the API gateway and container clusters.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If micro-service architecture is implemented to achieve scalability and independent evolution, then system flexibility and availability are improved, but network overhead and latency increase significantly
Solution Approach 1:
The patent merges multiple split requests into a single merged request when they share the same target service and can be processed together. This reduces the number of network round trips from multiple individual requests to a single consolidated request, thereby reducing network latency while preserving the micro-service architecture's flexibility benefits
2Ease of manufacture
If micro-service architecture is implemented to enable independent evolution, then system maintainability is improved, but network overhead and processing costs increase
Solution Approach 1:
The patent consolidates multiple requests into a single merged request that is processed by the target service and then split into individual responses. This approach reduces network overhead and processing costs while maintaining the independent evolution capability of micro-services, as each service can still be developed and deployed independently
Data Source
AI summary
A computer-implemented method includes receiving an initial request from a client, splitting the initial request into a plurality of split requests based on a business logic, acquiring mapping information associated with the plurality of split requests, determining, based, at least in part, on the mapping information, respective split requests included in the plurality of split requests that are candidates for merger into a merged request, merging the respective split requests that are determined to be candidates for merger into one or more merged requests, and sending the one or more merged requests to one or more nodes capable of processing the one or more merged requests.


