Kubernetes Rollback via API Trace Mappings
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In Kubernetes distributed systems, conventional rollback methods for service failures are limited by supporting only two-level transactions and requiring all services to be idempotent, leading to data inconsistency and inefficiency in rolling back entire invocation chains.
Innovation Solution
A method and system for managing multiple chain transaction rollback in a distributed system, utilizing a master API gateway with a validator and runner component to identify failed services, retrieve compensation transactions, and execute a rollback chain, supporting both transactional and non-transactional services and ensuring data consistency.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If saga method is used for service failure rollback, then service failures can be addressed with local transactions, but the system is limited to two-level transactions and requires all services to be idempotent
Solution Approach 1:
The patent segments the monolithic saga rollback process into fine-grained compensation transactions for each service in the invocation chain. Each service's compensation transaction is independently defined and executed, allowing multi-level transaction support beyond the traditional two-level limitation. This segmentation enables selective rollback of specific services rather than requiring all services to participate in a single unified transaction.
Solution Approach 2:
The patent introduces a new dimension of transaction hierarchy by implementing nested compensation transactions. Instead of flat two-level transactions, the system supports multi-level nested transactions where compensation transactions can contain sub-transactions. This dimensional change allows the system to handle complex service chains with varying transaction depths without requiring all services to be idempotent.
2Ease of manufacture
If conventional rollback methods are used, then implementation is simpler, but the system cannot support both transactional and non-transactional services in the same invocation chain
Solution Approach 1:
The patent applies local quality by allowing different services in the invocation chain to have different transactional characteristics. Each service can be marked as transactional or non-transactional based on its specific requirements. The compensation transaction mechanism adapts to each service's nature, applying appropriate rollback strategies locally rather than enforcing a uniform approach across all services.
Solution Approach 2:
The patent creates a universal compensation transaction framework that can handle both transactional and non-transactional services through a single unified mechanism. The system provides multi-functionality by supporting multiple service types, transaction levels, and rollback strategies within the same framework, eliminating the need for separate handling approaches for different service categories.
3Reliability
If all services in the invocation chain are rolled back to ensure data consistency, then data consistency is maintained, but the rollback process becomes inefficient and time-consuming
Solution Approach 1:
The patent implements partial action by selectively rolling back only the necessary services in the invocation chain rather than forcing a complete rollback of all services. The system identifies which services actually require compensation based on their transactional nature and failure points, executing compensation transactions only for those specific services. This partial approach maintains data consistency while significantly improving rollback efficiency by avoiding unnecessary rollback operations.
Data Source
AI summary
Managing multiple chain transaction rollback on a native cloud environment in a Kubernetes distributed system which extends API capabilities to build compensate API mappings which are used to reverse the invocation chain and stores the mappings in a key value store. An embodiment of the present invention extracts the reverse invocation chain from a framework of libraries and mapping API to check whether rollback is necessary when a service fails. An embodiment of the present invention executes an entire whole rollback.