---
title: 'ADR-014: Move session storage to Redis'
author: Priya Raman
skin: rfc
accent: #2563eb
numbered: true
toc: true
---

> **Status:** Accepted · **Date:** 2026-06-24 · **Deciders:** Platform guild
> **Supersedes:** ADR-006 (sticky sessions at the load balancer)

# Context

Sessions live in each API node's memory, so the load balancer has to pin every
user to one node. That pinning is now the main reason we cannot deploy during
business hours: draining a node logs out everyone assigned to it.

Traffic has roughly tripled since ADR-006. At 12 nodes, one node draining signs
out about 8% of active users.

# Decision

Move session storage to a managed Redis cluster, keyed by session id, with a
30-day TTL. API nodes become stateless and the load balancer moves to plain
round-robin.

# Consequences

**We gain**
- Rolling deploys with no forced logouts.
- Sessions survive a node loss instead of vanishing with it.
- Session state becomes inspectable during incidents.

**We accept**
- Redis becomes a hard dependency on the login path; an outage logs everyone out.
- One extra network hop per authenticated request — measured at 3–6 ms in staging.
- Roughly $340/month for the managed cluster.

**We must**
- Add a circuit breaker so a Redis timeout degrades to a re-login prompt rather
  than a 500.
- Alert on Redis memory above 70%; at current growth that is about 14 months away.

# Alternatives considered

| Option | Why not |
| :----- | :------ |
| Keep sticky sessions | Does not solve the deploy problem, which is the whole point |
| Signed stateless JWTs | We cannot revoke on demand, and Security has said no |
| Postgres session table | Works, but adds write load to the database we are trying to protect |

# Rollout

1. Dual-write sessions to memory and Redis; read from memory. *(1 week)*
2. Flip reads to Redis behind a per-tenant flag; memory stays as fallback. *(1 week)*
3. Remove the memory path and switch the balancer to round-robin. *(1 day)*

Rollback is the flag, at any point before step 3.