Message-based Stateful Microservice Migration (MS2M)

• Message-based Stateful Microservice Migration (MS2M) is a live migration scheme that uses message brokers to replay events and rebuild a service's state with minimal downtime.
• It employs a five-phase workflow—checkpoint creation, transfer, restoration, message replay, and finalization—to maintain service continuity during dynamic relocations.
• MS2M has evolved into Kubernetes-native and protocol-driven frameworks that reduce downtime and ensure zero message loss, addressing challenges of event-driven, stateful systems.

Message-based Stateful Microservice Migration (MS2M) is a live migration scheme for stateful microservices in edge and cloud environments that utilizes the underlying messaging infrastructure to reconstruct a service’s state at its new location by capturing and replaying relevant messages (Dinh-Tuan et al., 2022). It addresses the practical constraint that not every microservice can be deployed as a stateless instance, a constraint that makes conventional live migration techniques suboptimal for event-driven applications. In the literature, MS2M has evolved from a message-broker-based migration method into a broader family of Kubernetes-native, protocol-driven, and orchestration-centric techniques for preserving service continuity while relocating stateful components (Dinh-Tuan et al., 6 Sep 2025).

1. Problem setting and conceptual basis

MS2M emerges from a deployment environment in which cloud and edge infrastructures host interdependent microservices that may need to be reallocated dynamically at runtime. The motivating problem is the migration of stateful microservices, especially when service state is not confined to an external database and therefore cannot be preserved simply by redeploying a stateless replica. In this setting, directly transferring in-memory state can be complex and can increase downtime, whereas MS2M exploits message brokers already present in event-driven systems to rebuild state at the destination by replaying the state-altering message history (Dinh-Tuan et al., 2022).

The approach is framed against the limitations of stop-and-copy migration. Under stop-and-copy, the entire service is halted, all state is transferred, and only then is the target launched; service is unavailable for the full transfer interval. MS2M instead confines the interruption to a brief checkpointing window and performs most synchronization while the source instance continues to serve requests. This design is explicitly intended for event-driven microservices architectures that use asynchronous message brokers such as AMQP, MQTT, and RabbitMQ, and it is described as applicable across containers, virtual machines, edge deployments, and cloud-to-cloud migration scenarios (Dinh-Tuan et al., 2022).

A frequent misconception is that stateful migration can be reduced to container restart and persistent storage recovery. The Kubernetes availability study shows why this is insufficient for many stateful services: standard controllers permit pod and data redundancy, but they do not natively provide ready failover for stateful microservices because only the original pod can access its Persistent Volume and other pods are unaware of failure and cannot promptly take over (Vayghan et al., 2020). MS2M addresses a different layer of the problem: it treats the message stream itself as the synchronization substrate for live handoff.

2. Migration workflow and core mechanisms

The canonical MS2M workflow is described as a five-phase migration scheme composed of checkpoint creation, checkpoint transfer, service restoration, message replay, and finalization (Dinh-Tuan et al., 2022). During checkpoint creation, the Migration Manager issues a ServicePauseRequest, the service unsubscribes from the main message queue, and a checkpoint of the microservice is created, for example with CRIU. At that moment, a secondary replay queue is created to capture all new inbound messages to the main queue since migration initiation; the original service then resumes, so the downtime is limited to the checkpoint creation window.

Checkpoint transfer is asynchronous. The checkpoint image is moved to the target host while the original instance continues normal execution. In the restoration phase, the checkpoint is restored at the target as a new service instance, but the restored instance initially subscribes only to the secondary queue and does not yet emit output. This restriction is central: it allows the target to converge to the source state without externally observable duplication or premature responses (Dinh-Tuan et al., 2022).

The replay phase reconstructs the destination state. The restored instance replays the buffered messages from the secondary queue while the source remains active. Finalization occurs when synchronization is considered complete, using a LastMessageProcessedID indicator; at that point the target switches to the main queue, begins actual output or response generation, and the original instance is stopped and decommissioned. The essential mechanism is therefore not merely checkpoint transport, but checkpoint-plus-replay: the checkpoint supplies a base state, and the message backlog carries the state delta accumulated during migration (Dinh-Tuan et al., 2022).

This design is architecturally distinct from approaches that depend on sidecars, transparent proxies, or direct memory transfer alone. Its state transfer logic is explicit, application-visible at the messaging layer, and aligned with the event histories already used by many microservice systems.

3. Performance profile, benefits, and limits

The original MS2M evaluation reports that stop-and-copy completed in 4472.72 ms, whereas MS2M required 4852.86 ms, approximately 8.5% longer in total migration time (Dinh-Tuan et al., 2022). The critical metric, however, is service downtime rather than end-to-end migration duration. Under stop-and-copy, service downtime was 4472.72 ms; under MS2M, it was 3581.84 ms, a 19.92% reduction. The reported interpretation is that MS2M reduces effective downtime by nearly 20% compared to stop-and-copy while incurring only a minor increase in total migration time (Dinh-Tuan et al., 2022).

The benefits are tied to a specific trade-off structure. Because the source continues serving requests during transfer and most of replay, MS2M decouples a substantial portion of migration work from the outage window. At the same time, the method introduces a replay phase whose duration depends on the arrival rate of new messages and the processing capacity of the destination. This suggests that downtime and total migration time are not optimized by the same mechanism: the source-visible interruption can fall while the background synchronization interval grows.

The limitations are explicit. If the message arrival rate outpaces processing during replay, the replay phase may be unbounded in the worst case; the approach temporarily doubles resource usage because source and target run concurrently; it depends on applications already using message queues for all state-altering events; and if the source fails during replay, migration completeness and consistency are at risk (Dinh-Tuan et al., 2022). The paper also notes that large state snapshots and high transaction or state-change rates degrade checkpoint and replay efficiency. These constraints delimit the class of systems for which MS2M is effective: message-centric, replay-compatible, and operationally tolerant of a bounded overlap period.

4. Kubernetes-native realizations and high-availability extensions

Kubernetes has become the principal environment in which MS2M-style migration has been extended beyond its original formulation. One precursor is the HA State Controller for stateful microservice based applications on Kubernetes. That controller pairs pods into active and standby roles, creates a replication service for each pair, replicates state via HTTP, and redirects client traffic by ensuring that the application service routes only to pods labeled as active (Vayghan et al., 2020). On failure, the standby is promoted, application service endpoints are immediately updated, and the promoted pod restores the latest persisted state and resumes service. The paper reports that this controller can improve the recovery time of stateful microservice based applications by 50%, and the summary explicitly relates the design to MS2M because it automates state transfer, failure detection, and role reassignment through message-based transmission and service redirection (Vayghan et al., 2020).

A later Kubernetes-specific development integrates MS2M with Forensic Container Checkpointing (FCC). In that design, a Migration Manager on the Kubernetes master node retrieves pod configurations, triggers checkpoints for all containers in a pod using FCC, constructs checkpoint images, pushes them to an image registry, and restores them on target nodes (Dinh-Tuan et al., 6 Sep 2025). The extension adds support for StatefulSet-managed pods and introduces a Threshold-Based Cutoff Mechanism to cope with high incoming message rates. The evaluation reports that, for individual pods, MS2M reduces downtime by 96.986% compared to cold migration methods, while the StatefulSet approach provides greater flexibility in managing stateful services (Dinh-Tuan et al., 6 Sep 2025).

StatefulSet identity constraints became the focus of SHADOW, a Kubernetes-native framework that implements MS2M as a Kubernetes Operator. SHADOW introduces the ShadowPod strategy, in which a shadow pod is created from a CRIU checkpoint image on the target node while the source pod continues serving traffic, enabling concurrent operation during message replay (Dinh-Tuan, 26 Mar 2026). For StatefulSet workloads, SHADOW adds an identity swap procedure with the ExchangeFence mechanism; the shadow pod is re-checkpointed, a StatefulSet-owned replacement is created, and both message queues are drained to guarantee zero message loss during handoff. Across 280 migration runs over four configurations and seven message rates, the paper reports that, compared to the sequential baseline on the same StatefulSet workload, the ShadowPod strategy reduces the restore phase by up to 92%, eliminates service downtime entirely, reduces total migration time by up to 77%, and exhibits zero message loss across all runs (Dinh-Tuan, 26 Mar 2026).

Taken together, these Kubernetes studies show that MS2M has shifted from a broker-level migration technique to a controller and operator design pattern. The recurring elements are checkpoint/restore, secondary buffering, message replay, and routing or identity management during handoff.

5. Protocol-driven management and orchestration frameworks

MS2M also intersects with work that formalizes management actions as explicit protocol messages rather than relying on transparent service-mesh interception. SSMMP/v1.1 defines a simple protocol for Service Mesh management in which a Manager, Agents, and Service Instances exchange plain-text messages for execution, session establishment, session closing, and shutdown (Ambroszkiewicz et al., 2023). Microservices are directly involved in configuration of their communication sessions, sidecars are no longer needed, and only minor and generic modifications limited to network connections are required. For interrupted sessions, the protocol assumes that service state, when needed, is stored in external Backend-as-a-Service (BaaS), so a re-instantiated service can establish a new session and fetch the necessary state to continue (Ambroszkiewicz et al., 2023).

SSMMP does not implement the original MS2M replay pattern, but it addresses adjacent concerns: explicit session continuity, automated reconfiguration, and minimal interference with business logic. Its message formats such as execution_request, session_request, session_ack, and graceful_shutdown_request turn lifecycle operations into auditable protocol exchanges. In that sense, it can be read as a control-plane complement to migration schemes that depend on explicit, message-visible handoff.

MOSE extends the message-driven orchestration perspective to edge migration. It introduces a MOSE Orchestrator, MOSE Agents on source and destination edge servers and the client device, and a Zenoh pub/sub message bus for coordinating checkpoint, transfer, network reconfiguration, and restore (Calagna et al., 10 Jun 2025). The framework uses the PAM analytical model to configure migration against application and network KPI targets, including migration downtime, migration duration, and resource usage. Its experiments report up to 77% decrease of the migration downtime with respect to the state of the art, along with use cases involving a UAV autopilot microservice and a multi-object tracking task (Calagna et al., 10 Jun 2025). MOSE thus emphasizes orchestration optimality and QoE-aware parameter selection, whereas original MS2M emphasizes state reconstruction through message replay.

6. Relation to adjacent state-migration research and open questions

MS2M belongs to a broader research landscape on state migration and reconfiguration. In distributed streaming dataflows, Megaphone provides a latency-conscious migration mechanism whose distinctive characteristics are that migrations can be subdivided to a configurable granularity to avoid latency spikes and can be prepared ahead of time to avoid runtime coordination (Hoffmann et al., 2018). Implemented as a library on an unmodified timely dataflow implementation, Megaphone reduces service latencies during reconfiguration by orders of magnitude without significantly increasing steady-state overhead. Although it operates in dataflow engines rather than microservice brokers, it addresses a comparable handoff problem: how to move state without global pauses, excessive latency spikes, or full duplication of execution (Hoffmann et al., 2018).

The broader cloud-application literature situates MS2M among three major approaches to migrating transactional cloud applications: microservices, actors, and stateful dataflow systems (Laigner et al., 23 Apr 2025). That literature highlights challenges that remain unresolved even when migration mechanisms improve: ensuring state consistency, maintaining durability, managing the application lifecycle, handling message delivery, coordinating scaling, and supporting live upgrades. It also emphasizes that exactly-once message processing is difficult, that idempotency and deduplication often remain application responsibilities, and that realistic benchmarks for message- and state-intensive cloud applications are still lacking (Laigner et al., 23 Apr 2025).

These open questions temper any narrow reading of MS2M as a complete solution. MS2M addresses a specific systems problem—live relocation of stateful microservices by combining checkpointing with message replay—but it does not remove the need for explicit guarantees about consistency, durability, delivery semantics, and lifecycle control. The trajectory from the original broker-based design to Kubernetes operators, service-management protocols, and KPI-aware edge orchestrators indicates that message-based migration is increasingly treated as one component of a larger stateful application management stack rather than as an isolated runtime primitive.