Docker Swarm rolling update on Raspberry Pi leaves in‑memory cache stale after task replacement

Goal: achieve a zero‑downtime migration of a small application on a Raspberry Pi Docker Swarm cluster while preserving any in‑memory state such as caches or session data during a rolling update.

Constraint: Docker Swarm’s rolling update mechanism drains the old task, waits for the replacement to become healthy, and then proceeds, but it provides no built‑in pre‑stop hook to flush or replicate in‑memory data before the old task is terminated. The update’s success therefore depends on external storage or on the application’s ability to transfer state within the healthcheck window.

What mechanisms can be used to synchronize in‑memory state before the old task is stopped?
How can a healthcheck be designed to confirm that state transfer has completed without blocking the update?
Is there a way to extend the Swarm update strategy with a custom pre‑stop step using configs, sidecar containers, or external orchestration?