Phased Version Upgrade Routing in Web Systems
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Web-based business information systems face challenges in upgrading to new versions while maintaining access for both upgraded and non-upgraded accounts, especially when the new version has a modified database schema that is not downward compatible with the existing schema, and require minimal client-side changes and efficient handling of traffic to ensure system availability.
Innovation Solution
Implementing a phased rollout approach with a common set of web servers and segregated application servers and databases for upgraded and non-upgraded accounts, using a login router database to route client requests based on account status and version, allowing seamless access without changing external entry point URLs and minimizing hardware and network loading.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a new version of the web-based business information system is rolled out with a modified database schema, then advanced users can access new features and advantages, but non-upgraded users cannot access the new version and may experience access issues
Solution Approach 1:
The system is segmented into multiple application server groups (first group for current version, second group for new version) that can independently service different user populations. This allows upgraded accounts to access the new version with advanced features while non-upgraded accounts continue to access the current version without disruption, resolving the contradiction between adaptability and reliability.
Solution Approach 2:
A login router database is introduced as an intermediary component that receives client requests and intelligently routes them to the appropriate application server group based on account upgrade status. This mediator enables seamless version management, allowing the system to maintain reliability for all users while providing adaptability for upgraded accounts.
2Adaptability or versatility
If separate web servers are used for upgraded and non-upgraded accounts, then version isolation is achieved, but system complexity and hardware requirements increase
Solution Approach 1:
A common set of web servers is designed to serve multiple functions by routing requests to different application server groups. These web servers act as universal entry points that can handle requests for both upgraded and non-upgraded accounts without requiring separate web server infrastructures, reducing device complexity while maintaining version management capabilities.
Solution Approach 2:
The login router database serves as an intermediary that manages version routing logic, eliminating the need for complex separate web server configurations. By centralizing the routing decision-making process, the system achieves efficient version management with minimal additional infrastructure complexity.
3Adaptability or versatility
If URL changes are required for upgraded accounts, then access to new version can be controlled, but client-side changes and configuration updates are required
Solution Approach 1:
The common web servers provide universal access points that work for both upgraded and non-upgraded accounts without requiring URL changes. Clients can access the system using the same external entry point URLs regardless of account upgrade status, while the backend routing logic handles version differentiation, eliminating client-side configuration changes.
Solution Approach 2:
The system automatically determines the appropriate version routing based on account information stored in the login router database, without requiring clients to manually configure or change URLs. The routing decision is made automatically based on account upgrade status, maintaining ease of operation while providing version access control.
4Stability of the object's composition
If all accounts are upgraded simultaneously, then system consistency is maintained, but traffic management and system stability become difficult to maintain
Solution Approach 1:
The user base is segmented into different account groups that can be upgraded at different paces. The first group of accounts runs the current version while the second group upgrades to the new version, allowing controlled, phased rollouts. This segmentation enables traffic management and stability maintenance during transitions, avoiding the productivity issues of simultaneous upgrades.
Solution Approach 2:
The system dynamically routes traffic to different application server groups based on real-time account upgrade status. This dynamic routing capability allows the system to adapt to changing traffic patterns during phased rollouts, maintaining stability and handling efficiency as accounts transition between versions at different rates.
Data Source
AI summary
A method, system, computer program product, and related business methods for phased rollout of an upgraded version of a web-based business information system are described. URLs associated with client requests remain the same even where the target subscriber accounts have been upgraded. Client requests for both upgraded and non-upgraded accounts are received by a common set of web servers. Client requests representing external entry points are trapped, and the receiving web server accesses a login router database to determine whether the target subscriber account is upgraded or non-upgraded, and then transfers the request to an appropriately-versioned application server. Application server sets are mapped to database sets according to system version, allowing the upgraded system database schema to be substantially different than the non-upgraded database schema. An early adopter program business method leveraging the abilities of such web-based business information system is also described. Applications to environments other than phased rollout are described, such as URL-agnostic differentiation and routing of client requests according to class-of-service of the target subscribing account.