Shadow Client Architecture for Near-Zero Downtime System Upgrades
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional system update methods often require downtime to handle software and database structure changes, especially when updating system data configurations, as they lack the necessary data separation and recalculate process relationships, disrupting user access in cloud-based business systems.
Innovation Solution
The method involves creating a shadow client with read-only views and projection views, allowing for near-zero downtime upgrades by storing customization changes in a virtual transport and switching to a new access schema, using database identity views to separate tables, and running automated tests to ensure compatibility with production data.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If conventional system update methods are used to handle software and database structure changes, then system updates can be completed, but user access is disrupted and downtime occurs
Solution Approach 1:
The system is segmented into multiple clients (first client, second client, third client) that can operate independently. The second client serves as a shadow client that can be updated without affecting the first client's operations. This segmentation allows updates to be applied to one client instance while others continue serving users, thereby maintaining system availability during updates.
Solution Approach 2:
The shadow client (second client) is created and configured in advance before the actual system update is needed. By preparing the updated version in the shadow client beforehand and validating it through automated tests, the system can switch to the pre-prepared updated version quickly, minimizing the actual downtime when the update is deployed.
2Adaptability or versatility
If system data configuration schema is updated, then new system version requirements are met, but recalculation of process relationships is required causing downtime
Solution Approach 1:
A shadow client is created as a copy of the production client, containing duplicate data and configuration. This copy can be updated independently without affecting the original production system. The shadow client serves as a testbed for applying schema changes and validating them before any potential switch to the updated version.
Solution Approach 2:
The shadow client acts as an intermediary between the original production system and the updated system version. It allows configuration changes to be applied and tested in isolation, serving as a buffer that prevents direct interference with the running production system during update validation.
3Reliability
If automated tests are run against live production data, then compatibility is ensured, but data access complexity increases
Solution Approach 1:
The shadow client serves as an intermediary layer that provides read-only access to production data through projection views. This intermediary structure allows automated tests to run against data that mirrors production data without directly accessing or modifying the actual production database, thereby ensuring compatibility while maintaining a clear separation between test operations and production data access.
Solution Approach 2:
Instead of directly accessing production data, the system creates a copied version in the shadow client that can be queried and tested. This copy maintains the same data structure and relationships as production data, allowing comprehensive compatibility testing while isolating test operations from the production environment.
4Reliability
If read-only views are used in shadow client, then data integrity is maintained, but full customization capability is limited
Solution Approach 1:
The system segments customization capabilities across multiple clients. The shadow client has read-only views for data integrity during testing, while the production client maintains full customization capability. Configuration changes are applied to the shadow client in a controlled manner, and validated customizations can be transferred to the production client, thus distributing the customization function across different client instances.
Solution Approach 2:
The shadow client with read-only views acts as an intermediary validation environment. It allows configuration changes to be tested against production data without risking data integrity. Once validated, the proven customizations are applied to the production client which then gains the customized functionality, thus maintaining data integrity during testing while achieving full customization in the production system.
Data Source
AI summary
The disclosure generally describes methods, software, and systems for completing near-zero downtime system upgrades. A new access schema for a new version of a system is created and stored. The system uses an existing access schema corresponding to a current version of the system. For the new version of the system, a shadow client is created that includes customizations and read-only views to master data and application data. Projection views into the new access schema are created from the shadow client. Using the new access schema and the shadow client, customization changes to the master and application data are automatically performed and stored at the shadow client. Upon receiving a request to switch to the new version of the system, the virtual transport is imported to a shadow-phase of the production client. The production client is switched to begin using the new access schema.