ADR-014: Move session state from signed cookies to Redis

Consensus

All reviewers agree the single-node Redis design introduces an unacceptable availability risk on the authentication hot path and lacks production-grade hardening for security, observability, and data durability. While moving sessions to Redis improves revocation capability, the current proposal would create catastrophic outage exposure and authorization stalemate without remediation.

Findings

Recommendations — ranked, not scored

1. now Deploy a Multi-AZ Redis cluster with automatic failover to eliminate the single-node outage risk on the authentication path.
2. now Add a user_id-to-sessions secondary index and close the dual-read hole so revoked sessions are rejected even during migration.
3. next Fetch RBAC authoritatively per request or implement active invalidation; do not rely on long-lived cached roles for access decisions.
4. next Define throttled TTL refresh, eviction policy, persistence configuration, and encryption before the production rollout.

Coverage

• resilience — gap. Single-node Redis on the auth hot path with no replication or failover is an acknowledged total-outage risk.
• security — partial. Revocation is improved, but stale role caching, missing encryption, and migration fallback holes remain.
• observability — gap. Latency, error rate, hit ratio, and eviction metrics are absent; there are no acceptance criteria or alerting rules.
• operations — gap. Rollback procedures, capacity margins, and Redis tuning parameters like maxmemory-policy are undefined.

Bottom line

This is an architecture decision for moving user sessions to Redis, a fast data store. The reviewers concluded that the current design is not safe for release because one Redis failure could log out or block all authenticated users, and other security and operating controls are missing.

A score of 35/100 means the document has serious problems that make the proposed design unsafe for production. The low score reflects major gaps in reliability, security, monitoring, and operating plans.

Key points

• A single Redis server sits on the login and access-check path, so its failure or maintenance could cause a total outage for authenticated users.
• The design cannot quickly revoke every session for one compromised user because it does not keep a direct list of that user's sessions.
• User roles are stored in sessions for up to 14 days, so removed permissions may still work until a session expires or is manually deleted.
• During migration, a session removed from Redis may still be accepted through the old cookie system, leaving revoked or stolen sessions usable.
• Refreshing session expiration on every request creates extra write load, while durability, encryption at rest, and rules for removing old data are not defined.
• The document also lacks required monitoring, alerts, rollback steps, capacity limits, and Redis configuration details.

What to do

1. Replace the single Redis server with a multi-location Redis cluster that can automatically switch over after a failure.
2. Add a user-to-session index and ensure that revoked sessions are rejected during the migration, including when the old cookie fallback is checked.
3. Do not rely on long-lived stored roles for access decisions; get current roles for each request or actively remove outdated role data.
4. Before production, define limits on session-expiration updates, data-removal rules, persistence, and encryption.
5. Define monitoring, alerts, rollback procedures, capacity margins, and Redis tuning settings.