Static Token Bucket Rate Limiting for API Quotas

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing API rate limiting methods, such as token bucket algorithms, face inefficiencies when varying bucket sizes are required to enforce different service levels for developer applications, leading to increased processing complexity and slower response times due to the need to verify quota compliance.

Innovation Solution

Implementing a system that uses static token buckets with varying numbers of tokens requested for each API request, rather than altering bucket sizes, to enforce rate limits, allowing for configurable and efficient rate limiting without the complexity of managing different bucket sizes.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If token bucket algorithms are used to enforce rate limits by varying bucket sizes, then different service levels can be enforced, but processing complexity increases and response times slow down

Engineering Contradiction:
Improverate limiting configurabilityVSAvoidprocessing complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

Instead of varying the bucket size to enforce different rate limits, the patent inverts the approach by using a fixed bucket size and varying the number of tokens consumed per request. This inversion simplifies the token bucket management while achieving the same rate limiting effect through a different mechanism.

Inventive Principle:
Principle #13The other way round (Inversion)

Solution Approach 2:

The patent changes the parameter being varied from bucket size to token consumption amount. By keeping the bucket size fixed and instead varying how many tokens are removed per request based on the configured rate, the system achieves configurable rate limiting without the complexity of managing multiple bucket sizes.

Inventive Principle:
Principle #35Parameter changes

2Speed

If verification of quota compliance is conducted rapidly, then response time is maintained, but processing overhead increases

Engineering Contradiction:
Improveresponse timeVSAvoidprocessing overhead
Core Design Contradiction:
SpeedVSLoss of energy

Solution Approach 1:

The patent extracts the rate limiting logic from the token bucket management. By separating the determination of tokens needed (based on configured rate) from the actual token bucket operations, the system reduces processing overhead while maintaining rapid response times.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent introduces an intermediary layer that calculates how many tokens should be removed based on the configured rate and current bucket state, rather than directly managing variable-sized buckets. This intermediary calculation simplifies the overall processing while maintaining enforcement accuracy.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS8681630B1Configurable rate limiting using static token buckets, and applications thereof
Publication Date: 2014.03.25 GOOGLE LLC
  • US8681630B1 patent drawing
  • US8681630B1 patent drawing
  • US8681630B1 patent drawing

AI summary

A system disclosed rate limits API requests. The system includes an API server that receives an API request from a developer application at an API server and a token bucket to rate limit API requests from the developer application. A token query translation module determines a number of tokens needed to process the API request based on a rate configured in predefined policy data for the developer application and a replenish rate of the token bucket. The number of tokens inversely corresponds to the rate configured in the predefined policy data. A token request module instructs the API server to process the API request if the token bucket has sufficient tokens and reduces the number of tokens in the token bucket for the developer application by the number of tokens needed to process the API request. In this way, the disclosed system effectively simulates buckets having configurable replenish rates.