Client Backoff Filter Proxy for Rate Limiting

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

When a server is overwhelmed by excessive requests, existing network traffic throttling schemes can consume valuable computing resources, and clients that do not comply with backoff requests can exacerbate the overload, leading to service unavailability.

Innovation Solution

Transferring the burden of generating backoff data packets to a proxy service, which dynamically generates backoff notices on a client-by-client basis, allowing the server to focus on processing requests while the proxy intercepts and blocks subsequent requests based on cached metadata.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If the server directly processes all incoming requests, then service availability is maintained, but the server becomes overwhelmed and computing resources are consumed excessively

Engineering Contradiction:
Improveservice availabilityVSAvoidcomputing resources consumption
Core Design Contradiction:
ReliabilityVSUse of energy by moving object

Solution Approach 1:

The patent introduces a proxy service as an intermediary between clients and the server. The proxy receives backoff data packets from the server, caches the metadata, and independently enforces rate limiting on subsequent requests. This mediator handles the computationally intensive task of request filtering, allowing the server to focus on processing legitimate requests without being overwhelmed by excessive traffic.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system segments the request handling functionality by separating the backoff enforcement logic from the server. The proxy service independently caches backoff metadata and makes autonomous decisions about blocking requests, dividing the workload between the proxy (filtering) and server (processing). This segmentation prevents the server from consuming excessive computing resources while maintaining service availability.

Inventive Principle:
Principle #1Segmentation

2Productivity

If the server generates backoff data packets for each client, then rate limiting is enforced, but the server's computational load increases

Engineering Contradiction:
Improverequest processing efficiencyVSAvoidsystem complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The proxy service performs self-service by autonomously caching backoff metadata and independently enforcing rate limiting policies without requiring continuous server intervention. Once the server sends the initial backoff data packet, the proxy independently determines whether to block subsequent requests based on cached information, reducing the server's computational burden and simplifying the overall system architecture.

Inventive Principle:
Principle #25Self-service

3Reliability

If clients do not comply with backoff requests, then service overload continues, but enforcing compliance consumes additional resources

Engineering Contradiction:
Improveservice stabilityVSAvoidenforcement mechanism complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The proxy service performs preliminary action by caching backoff metadata in advance and proactively blocking non-compliant requests before they reach the server. This preliminary enforcement mechanism ensures that clients must comply with backoff requests, preventing service overload without requiring complex real-time verification mechanisms at the server level.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS12199871B2Client side backoff filter for rate limiting
Publication Date: 2025.01.14 INTUIT INC
  • US12199871B2 patent drawing
  • US12199871B2 patent drawing
  • US12199871B2 patent drawing

AI summary

A method in a client backoff filter. The method includes receiving, from a server, a backoff data packet having backoff metadata. The method also includes saving the backoff metadata in a cache local to the client backoff filter. The method also includes receiving a subsequent request for service. The method also includes checking whether an attribute of the subsequent request for service matches the backoff metadata in the cache. The method also includes performing, responsive to checking, an action including at least one of the group including: blocking, responsive to the attribute matching the backoff metadata in the cache, transmission of the subsequent request for service to a server, and transmitting, responsive to the attribute failing to match the backoff metadata in the cache, the subsequent request for service to the server.