Cloudflare Workers KV ↔ Existing Session Store: Coordinating Stateful Cutover During Weighted Traffic Migration

Migration Goal

A small application currently hosted on a traditional backend must be moved to Cloudflare Workers while serving live traffic. The plan uses Workers Routes with percentage-based weights to shift requests gradually from the origin to the new Worker script, avoiding a hard DNS cutover.

Constraints and Uncertainty

Workers KV provides only eventual consistency (up to 60 seconds propagation across colos). The existing application relies on strongly consistent session data stored in an external Redis cluster. During the weighted migration window, some requests will hit the Worker (reading from KV) while others hit the origin (reading from Redis). KV writes initiated by the Worker may not be visible to subsequent origin requests routed to the same user, and vice versa. Route percentage weights apply per-colo, so traffic distribution varies by region, making the inconsistency window unpredictable. Additionally, Wrangler deploy replaces the entire script; there is no instant rollback API if the canary reveals state corruption.

Questions

1. What pattern ensures session continuity when traffic is split between a Worker reading from KV and an origin reading from Redis, given KV's 60-second eventual consistency?
2. Can the migration be structured so that a single user's requests remain pinned to one backend for the duration of their session without sacrificing the gradual percentage-based rollout?
3. If KV is used only as a write-through cache with the external Redis as source of truth, what cache-invalidation strategy prevents stale reads during the overlap period?