UI Data Request Caching and Deduplication Under API Rate Limits

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Traditional web development paradigms lead to duplication of work, inefficiencies, and inconsistencies due to narrowly focused libraries for API handling, caching, and logging, resulting in wasted development and computational resources, and inefficient handling of retries and requests across frontend and backend systems.

Innovation Solution

Implementing a common service layer with configurable caching, deduplication, and rate limit handling for user interface data requests, using modular API wrappers and deduplication caches to consolidate identical requests and manage retries, ensuring efficient and consistent coding across microservices.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If page-level data stores are used for caching and API handling, then each page can have its own customized handling, but code duplication occurs across multiple repositories and frameworks

Engineering Contradiction:
Improvecustomized handling per pageVSAvoidcode duplication across repositories
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements a universal service layer that provides caching, deduplication, and rate limiting functionality across multiple pages and frameworks. This service layer acts as a common foundation that can be reused throughout the application, eliminating the need for duplicating code in each page while still providing customized handling through configuration options.

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

Solution Approach 2:

The service layer serves as an intermediary between the user interface and the data sources, centralizing the handling of caching, deduplication, and rate limiting. This mediator approach allows pages to rely on the service layer for complex operations while maintaining their own specific requirements through configurable parameters.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Stability of the object's composition

If all code relies on the service layer within one repository, then code consistency is improved, but the repository becomes large, complex, and hard to manage

Engineering Contradiction:
Improvecode consistencyVSAvoidrepository size and manageability
Core Design Contradiction:
Stability of the object's compositionVSDevice complexity

Solution Approach 1:

The service layer is segmented into distinct, independent components for caching, deduplication, and rate limiting. Each component can be developed, tested, and maintained separately, reducing the complexity of the overall repository while maintaining code consistency. This modular approach allows teams to work on specific service layer components without affecting the entire codebase.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Complex service layer functionality is extracted into separate, reusable modules that can be independently managed. This extraction reduces the burden on the main repository by isolating complex logic into dedicated components that can be updated and maintained without impacting the entire codebase.

Inventive Principle:
Principle #2Taking out (Extraction)

3Adaptability or versatility

If components are rebuilt when moved between pages and user interface frameworks, then framework-specific logic can be implemented, but development efficiency decreases due to repeated work

Engineering Contradiction:
Improveframework-specific logicVSAvoiddevelopment efficiency
Core Design Contradiction:
Adaptability or versatilityVSProductivity

Solution Approach 1:

The service layer components are designed to be framework-agnostic and reusable across different user interface frameworks. By implementing a universal interface and configuration system, the same caching, deduplication, and rate limiting logic can be applied across various frameworks without requiring components to be rebuilt, thereby maintaining framework-specific capabilities while improving development efficiency.

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

4Reliability

If narrowly focused libraries are used for API handling, caching, and logging, then specific functions can be optimized, but development resources are wasted due to duplication

Engineering Contradiction:
Improvefunction-specific optimizationVSAvoidwasted development resources
Core Design Contradiction:
ReliabilityVSLoss of energy

Solution Approach 1:

The patent merges previously separate, narrowly focused libraries into a unified service layer that provides caching, deduplication, and rate limiting functionality. This consolidation eliminates duplication of effort across multiple libraries while maintaining the optimized, function-specific capabilities of each component. The unified service layer reduces development resources by providing a single source of truth for these critical functions.

Inventive Principle:
Principle #5Merging (Combining)

Data Source

PatentEP4548218B1Technologies for configurable caching, deduplication, and rate limit handling
Publication Date: 2026.02.18 GENESYS CLOUD SERVICES INC
  • EP4548218B1 patent drawingFigure 1
  • EP4548218B1 patent drawingFigure 2
  • EP4548218B1 patent drawingFigure 3

AI summary

A method for configurable caching, deduplication, and rate limit handling of user interface data requests according to an embodiment includes receiving a data request initiated by a user interface element of a user interface, determining whether a deduplication cache includes a deduplication entry associated with the data request, determining whether a main cache includes a cache entry associated with the data request in response to determining that the deduplication cache does not include the deduplication entry, determining whether the data request is associated with a rate-limited group of application programming interface endpoints in response to determining that the main cache does not include the cache entry or determining that the cache entry has expired, and making the data request to a backend system after a predefined server retry period associated with the rate-limited group has elapsed in response to determining that the data request is associated with the rate-limited group.