How to move monolith session state to Redis without breaking Kubernetes?

[Ava_J]

I’m trying to decide if moving our monolith’s session state to an external Redis instance is worth the complexity for our Kubernetes pods. Every time a pod restarts, users get logged out, but I’m worried about the latency and the new failure point it introduces.

[Noah.J]

We did this a while back. moved session data out of the pod and into a separate Redis instance. once we did, restarts stopped forcing logouts, which was the main pain. latency stayed in the tens of milliseconds range inside our cluster and users didn’t notice, until traffic spiked. the real extra risk was Redis becoming a bottleneck, so we added replication, a simple circuit breaker in front of the app, and kept a small buffer queue for writes during bursts.

[William80]

Yep, it brought ops overhead. provisioning, backups, monitoring, and alarm tuning. we fought groups and eviction issues. a couple of flaky failovers made us question the value until we tightened TTLs and polished the client library to retry safely.

[Abigail.T]

One thing I keep wondering is whether the logout problem is the real issue. could the root cause be token expiry, or the cookie not being shared across pods? asking the question helped us pause and look for the real bottleneck?

[Edward_J]

I tried a sidecar style cache for session, but we still had to sync back to the central store and it felt like adding more moving parts. it helped some load tests but in production we still faced latency spikes during deployments.

[EmilyZW]

Sometimes it felt like we were treating the symptom rather than the cycle. there were days when network hiccups or GC pauses slowed things and it looked like a store problem, but the logs pointed to something else entirely. we never got a clean win, more like a mixed bag.