Centralized Throttling Service for API Rate Limit Management

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Social networks' API rate limits are often exceeded when multiple instances of applications access data, leading to restrictions and errors, as the aggregate rate of API calls surpasses the allowed limits, even if individual instances comply.

Innovation Solution

A throttling service is implemented to manage API rate limits by generating tokens with varying rates and distributing them across queues associated with different content types, ensuring compliance with rate limits and executing a backoff policy to prevent further violations.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If multiple instances of applications access the API simultaneously, then the data collection capability and processing throughput are improved, but the aggregate API call rate exceeds the rate limit, causing rate limit errors and access restrictions

Engineering Contradiction:
Improvedata collection capabilityVSAvoidAPI access stability
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

A centralized throttling service is introduced as an intermediary between multiple application instances and the social network API. This service acts as a mediator that receives API call requests from multiple instances, aggregates them, and manages the combined rate to stay within API limits. The throttling service includes a rate limit manager that tracks cumulative call rates across all instances and a request router that distributes or delays requests to maintain compliance with rate limits while enabling parallel data collection.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent merges the rate limiting functionality from individual application instances into a single centralized throttling service. Instead of each instance independently managing its own rate limits (which leads to aggregate exceedance), all instances' API calls are combined and managed through one unified throttling service that enforces the rate limit on the aggregate traffic, allowing maximum parallel data collection while staying within limits.

Inventive Principle:
Principle #5Merging (Combining)

2Reliability

If a centralized throttling service is implemented to manage aggregate API calls, then rate limit compliance is improved, but the system complexity and infrastructure requirements increase

Engineering Contradiction:
Improverate limit complianceVSAvoidsystem architecture complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The centralized throttling service is designed to perform multiple functions: it acts as a rate limit enforcer, a request aggregator, a response distributor, and a monitoring system. By consolidating these functions into a single service, the patent reduces the need for multiple separate components that each instance would otherwise need, thereby managing complexity through multi-functionality rather than proliferation of components.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The throttling service implements feedback mechanisms where the rate limit manager continuously monitors the aggregate API call rate and adjusts request routing or timing accordingly. When the cumulative rate approaches the limit, the system automatically delays or queues additional requests. This closed-loop feedback control maintains compliance without requiring complex manual configuration or intervention.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS10783267B2Centralized throttling service
Publication Date: 2020.09.22 SALESFORCE INC
  • US10783267B2 patent drawing
  • US10783267B2 patent drawing
  • US10783267B2 patent drawing

AI summary

A method and system are provided that may centralize the management of applications that access the data of social networks via API calls. A central service may generate tokens at a generation rate that permit an application to access an API. The tokens may be distributed to queues associated with certain content types. The relative distribution of tokens to each queue may be determined by rules. A queue may release tokens to applications that function to access the content type associated with the queue. The token generation rate and rules may be selected to prevent violation of the rate limits for the API.