Live Stateful Component Updates in Containers

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing systems face challenges in updating stateful software components without incurring system downtime or losing state information, leading to inefficiencies and potential data loss during the patching process.

Innovation Solution

Implementing a system that deploys updated software components to containers while maintaining access to state information, using protocols to manage state information between components and route requests, allowing for live updates without downtime and ensuring accurate state preservation.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a temporary downtime is implemented to install the update, then the state information is preserved, but the system performance and business processes are negatively affected

Engineering Contradiction:

Improvestate information preservationVSAvoidsystem performance

Core Design Contradiction:

ReliabilityVSProductivity

Solution Approach 1:

The system is divided into multiple component instances (first instance, second instance) that can operate independently. The stateful component is segmented into separate deployable units within the container, allowing one instance to be updated while another continues serving requests, thus avoiding complete system downtime while preserving state through shared access to the state store.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The state information is stored in a persistent state store before the update occurs. The first instance of the stateful component writes state to this external store, and the second instance retrieves state from it before becoming active. This preliminary establishment of state persistence mechanisms allows seamless transitions without data loss or downtime.

Inventive Principle:

Principle #10Preliminary action

2Productivity

If the update is installed without downtime, then the system performance is maintained, but the state information may be lost

Engineering Contradiction:

Improvesystem performanceVSAvoidstate information preservation

Core Design Contradiction:

ProductivityVSReliability

Solution Approach 1:

An external state store acts as an intermediary between component instances. Instead of storing state in volatile memory that would be lost during updates, the state is persisted to an external store (database, file system, or cloud storage) that survives instance restarts. This intermediary preserves state information while allowing instances to be replaced during runtime.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The state information is copied from the first instance's memory to a persistent external state store before the first instance is terminated. The second instance then copies this state from the persistent store to its memory upon activation. This copying process ensures state preservation across instance transitions without requiring the original instance to remain active.

Inventive Principle:

Principle #26Copying

3Adaptability or versatility

If the first component is disabled and the second component is enabled, then the update is deployed, but all existing requests must be re-routed which involves downtime

Engineering Contradiction:

Improvecomponent update capabilityVSAvoiddowntime

Core Design Contradiction:

Adaptability or versatilityVSLoss of time

Solution Approach 1:

The system dynamically routes requests between component instances based on their availability and health status. Instead of static routing that requires complete reconfiguration during updates, the load balancer or service mesh dynamically adjusts routing to send new requests to the second instance while allowing the first instance to complete in-flight requests, enabling seamless updates without forced downtime.

Inventive Principle:

Principle #15Dynamics

Solution Approach 2:

The system maintains continuous service availability by ensuring that while the first instance is being updated, the second instance is already prepared and can immediately accept requests. The transition is designed so that useful action (processing requests) continues uninterrupted, with only a brief overlap period where both instances may be active but no gap where neither can serve.

Inventive Principle:

Principle #20Continuity of useful action

Data Source

PatentUS11231919B2Live updates of stateful components

Publication Date: 2022.01.25 SALESFORCE INC

AI summary

Methods, systems, and devices supporting live updates for stateful software components are described. A computing system may implement live updating for patching stateful software components. A device may execute a first set of requests at a first version of a software component deployed to a container, where the software component may be a stateful component associated with an in-memory state managed by the container. The device may receive a software patch that includes a second version of the software component from a user device, deploy the second version of the software component to the container, and route a second set of requests to the second version of the software component. The device may update the in-memory state of the software component based on the first version of the software component and the second version of the software component to maintain accurate state information across versions during the patching process.