Keeper Service for Rate-Limited Non-Tabular Database Queries
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing CaaS platforms face challenges in managing access to non-tabular databases, including redundancy in microservices, data security issues, and vulnerability to Denial of Service (DoS) attacks, which overload the database and cause system collapse.
Innovation Solution
Implementing a keeper service with a rate-limited mechanism that provides a unified API for accessing non-tabular databases, validating query paths, performing rate-limit calculations, and translating requests into vendor-neutral commands to control access and prevent overloading.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If unrestricted access to non-tabular database is allowed, then user query flexibility is improved, but database overload and system collapse occur due to DoS attacks
Solution Approach 1:
The patent introduces a keeper service as an intermediary layer between users and the non-tabular database. This keeper service receives user requests, validates query paths against predefined paths, performs rate-limit calculations, and translates vendor-specific requests into vendor-neutral commands. By placing this intermediary, the system maintains database stability while allowing flexible user queries, as the keeper service filters and controls access without restricting legitimate user needs.
Solution Approach 2:
The patent implements preliminary rate-limit calculations and query path validations before requests reach the database. The keeper service calculates rate limits based on parameters like query complexity and data volume, and rejects requests that would exceed these limits or use non-predefined query paths. This preliminary anti-action prevents DoS attacks and database overload before they can occur, while still allowing legitimate flexible queries within established boundaries.
2Adaptability or versatility
If multiple microservices are created for database access, then access flexibility is improved, but system redundancy and complexity increase
Solution Approach 1:
The patent makes the keeper service universal by enabling it to handle multiple types of database access requests from different users and applications through a single service instance. The keeper service validates various query paths, performs rate-limit calculations for different request types, and translates multiple vendor-specific database commands into vendor-neutral formats. This eliminates the need for multiple specialized microservices while maintaining access flexibility, thereby reducing system complexity and redundancy.
3Reliability
If query rate limiting is implemented, then database protection is improved, but query processing time increases due to additional validation steps
Solution Approach 1:
The patent performs rate-limit calculations and query path validations as preliminary actions before executing database queries. The keeper service establishes rate limits based on predefined parameters and validates query paths against an allowlist before processing requests. By performing these protective actions preliminarily and caching validation results, the system protects the database while minimizing additional processing time for legitimate queries.
Data Source
AI summary
Techniques for querying a nontabular database in a Containers-as-a-Service (CaaS) platform including using rate-limited mechanisms. A keeper service receives a vendor-specific request with a query path, validates it against predefined paths, and determines a parameter for rate-limit calculation. The request is translated into a vendor-neutral query command if the rate limit has not been reached, and then executed to access the database.