Smart Request System Dynamic Bulk Mode Switching

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current microservices architectures face performance bottlenecks due to the single request mode of communication, which is inefficient with increasing request body size, network latency, and data loss, leading to high overhead and reduced system performance.

Innovation Solution

Implementing a dynamic request mode using a smart request system that can switch between single request and bulk request modes based on metrics such as CPU usage, network latency, and packet loss rate, allowing for intelligent and efficient communication by sending requests in bulk when conditions are met.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Device complexity

If single request mode is used for service communication, then implementation simplicity is maintained, but communication overhead increases dramatically with increasing request body size and network latency

Engineering Contradiction:
Improverequest mode complexityVSAvoidcommunication efficiency
Core Design Contradiction:
Device complexityVSProductivity

Solution Approach 1:

The system dynamically switches between single request mode and bulk request mode based on real-time system conditions. A monitoring component tracks metrics such as queue depth, processing capacity, and network latency, and automatically adjusts the request mode accordingly. This dynamic adaptation allows the system to optimize communication efficiency without requiring complex manual configuration or prediction of future conditions.

Inventive Principle:
Principle #15Dynamics

2Productivity

If bulk request mode is used to reduce communication overhead, then communication efficiency improves, but system complexity increases

Engineering Contradiction:
Improvecommunication efficiencyVSAvoidrequest mode complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The system employs self-service mechanisms where service components automatically monitor their own performance metrics and queue states, then autonomously decide when to switch between single and bulk request modes. This self-regulation eliminates the need for external controllers or complex centralized management, reducing overall system complexity while maintaining the benefits of dynamic mode switching.

Inventive Principle:
Principle #25Self-service

3Use of energy by moving object

If single request mode is used, then network resource consumption per request is minimized, but total communication time increases due to repeated connection overhead

Engineering Contradiction:
Improvenetwork resource consumptionVSAvoidtotal communication time
Core Design Contradiction:
Use of energy by moving objectVSLoss of time

Solution Approach 1:

The system merges multiple individual requests into a single bulk request when conditions are favorable. By combining multiple requests that would otherwise require separate network connections and handshakes into one aggregated request, the system reduces the total number of connection establishment events, thereby decreasing overall communication time while maintaining efficient use of network resources.

Inventive Principle:
Principle #5Merging (Combining)

4Productivity

If dynamic mode switching is implemented, then communication efficiency is optimized, but control and measurement difficulty increases

Engineering Contradiction:
Improvecommunication efficiencyVSAvoidsystem state monitoring
Core Design Contradiction:
ProductivityVSDifficulty of detecting and measuring

Solution Approach 1:

The system implements continuous feedback loops where performance metrics such as queue depth, processing capacity utilization, and network latency are constantly monitored and fed back to the mode selection logic. This feedback mechanism enables the system to automatically adjust between single and bulk request modes based on real-time conditions, optimizing communication efficiency while using standard, well-defined metrics that are relatively straightforward to measure and interpret.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS20240411586A1Dynamic request mode using smart request system
Publication Date: 2024.12.12 SAP SE
  • US20240411586A1 patent drawing
  • US20240411586A1 patent drawing
  • US20240411586A1 patent drawing

AI summary

A first service of a microservices architecture may obtain a set of one or more metrics of the microservices architecture. The microservices architecture may include the first service, a second service, and a network, where the first and second services are configured to communicate with each other via the network. The first service may determine that the set of metrics satisfies one or more bulk mode conditions. The first service may identify a plurality of workers of the first service running in parallel to one another, where each worker is configured to execute a task. The first service may send a bulk request to the second service based on the determining that the set of metrics satisfies the one or more bulk mode conditions. The bulk request may comprise a corresponding request body portion for each worker in the plurality of workers.