Distributed Routing Matrix for Cloud Application Failover
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Reconfiguring a system to resiliently switch to a backup version of an application in cloud-based applications with multiple interacting subsystems is complex, time-consuming, and error-prone, especially when handling failures or performance degradation.
Innovation Solution
Each computing subsystem maintains a common routing matrix to identify and route messages to the appropriate instance of a hosted application, allowing for seamless switching between active and standby instances with minimal configuration changes by updating the routing matrix based on performance attributes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a system uses multiple hosted applications configured to interact with one another across distributed computing subsystems, then geographic distribution and backup capabilities are improved, but reconfiguring the system to switch to backup versions becomes complex and time-consuming
Solution Approach 1:
The system segments the routing logic into a centralized routing matrix that is separate from the application logic. Each computing subsystem maintains a local copy of the routing matrix, which divides the complex reconfiguration task into manageable updates of routing information rather than system-wide reconfiguration.
Solution Approach 2:
The routing matrix acts as an intermediary layer between computing subsystems and hosted applications. It absorbs the complexity of routing decisions and switchovers, allowing applications to remain simple while the routing matrix handles the complex logic of switching between active and backup instances across distributed subsystems.
2Reliability
If manual reconfiguration processes are used to switch to backup applications during outages, then system control is maintained, but the process becomes error-prone and time-consuming
Solution Approach 1:
The system performs preliminary actions by pre-configuring the routing matrix with multiple routing options including backup instances before outages occur. When an outage happens, the routing matrix can immediately switch to pre-planned backup routes without requiring real-time manual configuration, thus reducing reconfiguration time and errors.
Solution Approach 2:
The routing matrix enables self-service by automatically detecting routing failures and switching to backup routes without human intervention. The system monitors routing health and autonomously reconfigures paths when outages occur, eliminating manual reconfiguration steps and reducing both time and error risks.
3Stability of the object's composition
If routing information is centrally managed, then consistency across subsystems is improved, but update propagation becomes a bottleneck
Solution Approach 1:
The centralized routing matrix is segmented and distributed to multiple computing subsystems, with each subsystem maintaining a local copy. This segmentation allows parallel updates across multiple nodes simultaneously, improving update propagation speed while maintaining consistency through the distributed nature of the routing matrix copies.
Solution Approach 2:
The routing matrix implementation is dynamic, allowing subsystems to independently update their local copies based on current routing needs. The system transitions from static centralized control to dynamic distributed updates, where each subsystem can adapt its routing information independently while maintaining overall system consistency through the common routing matrix structure.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
In a system including a plurality of computing subsystems executing a set of hosted applications, each of the computing subsystems maintains a copy of a common routing matrix defining, for each hosted application, an identifier of a computing subsystem configured to host the application. A first intra-subsystem routing component of a first one of the computing subsystems receives a message; determines a target one of the hosted applications to process the message; identifies, according to the common routing matrix, a second one of the computing subsystems that executes the target hosted application; and in response to the identifying, provides the message and a routing indicator to a first inter-subsystem routing component of the first computing subsystem. The first inter-subsystem routing component the transmits the message to the second computing subsystem.