Adaptive API Rate Limiting via Dynamic Token Generation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing rate limiting methods in servers are inadequate for managing legitimate spikes in load during peak hours and fail to differentiate between priority-based requests, leading to potential security vulnerabilities and inefficiencies.

Innovation Solution

Implementing adaptive rate limiting through a management server that generates a lightweight JSON token (JWT) based on the client's workload, allowing subsequent servers to dynamically adjust API call permissions according to the client's priority and workload, thereby enabling secure and efficient resource allocation.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If static rate limiting is implemented with pre-set thresholds, then server security is improved, but legitimate spikes in load during peak hours are blocked and priority-based differentiation is lost

Engineering Contradiction:
Improveserver securityVSAvoidadaptive response to workload variations
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent implements dynamic rate limiting by replacing static pre-set thresholds with adaptive thresholds that are computed in real-time based on server workload conditions. The system dynamically adjusts the number of allowed API calls per client based on current server capacity, enabling the rate limiting mechanism to adapt to varying load conditions while maintaining security.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent changes the parameter of rate limiting from fixed static values to dynamic computed values. The system computes adaptive rate limits based on server workload metrics, transforming the rate limiting parameter from a constant to a variable that responds to changing system conditions, thereby resolving the contradiction between security and adaptability.

Inventive Principle:
Principle #35Parameter changes

2Productivity

If priority-based differentiation is implemented, then efficient resource allocation is improved, but system complexity increases

Engineering Contradiction:
Improveresource allocation efficiencyVSAvoidrate limiting system complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent introduces a token as an intermediary mechanism that carries priority information from the client to the server. The token encapsulates workload-related data and priority levels, allowing the server to differentiate and prioritize requests without requiring complex integrated analysis of each request's context, thus managing complexity while enabling priority-based resource allocation.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent implements preliminary action by having clients compute their workload before making API calls and encode this information in advance within a token. This pre-computation and pre-packaging of priority information simplifies the server-side processing, as the server only needs to read and act upon the pre-computed token data rather than performing complex real-time analysis.

Inventive Principle:
Principle #10Preliminary action

3Reliability

If token-based adaptive rate limiting is implemented, then differentiation between malicious and legitimate requests is improved, but additional processing overhead is introduced

Engineering Contradiction:
Improverequest validation accuracyVSAvoidtoken processing time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent applies partial action by implementing token-based validation only when necessary for rate limiting decisions, rather than processing all requests through the full token validation pipeline. The system selectively uses token information based on the specific rate limiting context, reducing unnecessary processing overhead while maintaining accurate differentiation between malicious and legitimate requests.

Inventive Principle:
Principle #16Partial or excessive action

Data Source

PatentUS11849040B2Adaptive rate limiting of API calls
Publication Date: 2023.12.19 MICRO FOCUS LLC
  • US11849040B2 patent drawing
  • US11849040B2 patent drawing
  • US11849040B2 patent drawing

AI summary

According to examples, an apparatus may include a processor and a memory on which are stored machine-readable instructions that when executed by the processor, may cause the processor to receive a request from a client for a status of the client, and based on the status of the client, generate a token associated with application programming interface (API) calls to be received from the client. In some examples, the token may include a value representing a priority for determining an adaptive rate limiting of the API calls to be received from the client. The processor may send a response to the request, in which the response may include the status of the client and the token.