suggestibility.ai
ADR-014: Move session state from signed cookies to Redis
A platform team proposes moving sessions out of signed cookies. Three reviewers.
- Board
- 3 reviewers
- Score
- 45 / 100
- What that means
-
Major issues
The board found serious problems with this document.
Consensus
The ADR proposes a functional session migration but has critical production gaps: a single Redis node creates an authentication SPOF, no persistence risks total session loss, and the migration lacks rollback controls. Stale permissions from cached roles and missing cookie hardening are significant security concerns.
Findings
Single Redis node is an auth SPOF
All reviewers agree: one ElastiCache node without replica or Multi-AZ means any Redis failure causes total authentication outage. No fallback path defined.
Raised by Principal Software Architect, Security and Reliability Reviewer, Product Delivery Lead
No persistence or durability for sessions
Redis is in-memory only; restarts or crashes wipe all active sessions. No RDB/AOF or managed persistence configured.
Raised by Principal Software Architect
Stale authorization via cached roles
Storing roles in the session body creates TOCTOU risk: revoked permissions persist up to 14-day TTL unless manual Redis DEL. No invalidation mechanism defined.
Raised by Security and Reliability Reviewer, Product Delivery Lead
Missing cookie security flags
New 64-byte opaque session cookie lacks mandated HttpOnly, Secure, and SameSite=Lax/Strict flags, exposing sessions to XSS theft.
Raised by Principal Software Architect, Security and Reliability Reviewer
Migration plan lacks feature flags and rollback
Dual-read relies on cookie TTL expiry without toggles, monitoring, or a tested rollback procedure. Risk of silent inconsistencies during cutover.
Raised by Product Delivery Lead
Dissent — recorded, not resolved
Cookie security flags rated Low severity; other reviewers rate Medium/High — Security and Reliability Reviewer
Majority view: Principal Architect and consensus view: missing HttpOnly/Secure/SameSite is a Medium-severity session hijacking vector requiring immediate fix.
Recommendations — ranked, not scored
- now Deploy Redis Multi-AZ replication group with automatic failover; enable persistence (RDB/AOF) or use managed service with durability.
- now Mandate HttpOnly, Secure, SameSite=Lax on session cookie; enforce TLS in-transit encryption for ElastiCache.
- next Resolve roles caching: either add versioned roles check with short TTL, or fetch roles per request. Document chosen trade-off.
- next Add feature flag (use_redis_sessions) for independent read/write toggle; define rollback runbook and migration metrics/alerts.
Coverage
- Availability — gap. No failover, no persistence, no fallback path
- Security — partial. Cookie flags missing; roles caching creates TOCTOU; no encryption-at-rest mentioned
- Operations/Migration — partial. Dual-read plan exists but lacks toggles, monitoring, rollback
- Data Integrity — gap. No durability, no revocation clarity, no audit logging
Bottom line
This document proposes moving user sessions to a Redis database. Reviewers found critical gaps that would cause total authentication outages and security risks if deployed as written.
A score of 45 out of 100 means the reviewers found serious problems with this architecture decision. Low scores indicate the document has significant flaws that must be fixed before implementation.
Key points
- Using only one Redis server creates a single point of failure; if it goes down, no one can log in.
- Sessions are stored only in memory, so any restart or crash wipes all active user sessions.
- User roles are cached in the session, so revoked permissions can stay active for up to 14 days unless manually cleared.
- The new session cookie lacks basic security settings, making it vulnerable to theft via cross-site scripting attacks.
- The migration plan has no way to toggle the new system on or off, no monitoring, and no tested plan to roll back if something goes wrong.
What to do
- Set up Redis with automatic failover across multiple availability zones and enable data persistence so sessions survive restarts.
- Add HttpOnly, Secure, and SameSite=Lax flags to the session cookie and require encryption for data in transit.
- Fix the stale permissions problem by either checking roles on each request or using a short cache time with versioning.
- Add a feature flag to control the migration, define metrics and alerts, and create a tested rollback procedure.
Where reviewers disagreed
One reviewer rated the missing cookie security flags as low severity, while the majority rated them medium or high. This disagreement affects how urgently the cookie fixes are prioritized.
The board
Read the document that was reviewed (3,233 characters)
ADR-014: Move session state from signed cookies to Redis
Status: Proposed
Date: 2026-07-28
Deciders: Platform team
Supersedes: ADR-006 (stateless signed-cookie sessions)
Context
Our web tier is stateless today. Session data lives in a signed cookie
(HMAC-SHA256, 4KB ceiling). Two constraints have made this uncomfortable:
- The cookie is now 3.1KB average and 3.9KB at p99. We are one feature away
from the browser limit, and every request carries it on the wire.
- We cannot revoke a session. Logout clears the cookie client-side, but a
copied cookie stays valid until its 14-day expiry. Support has escalated
this twice after laptop-theft reports from enterprise customers.
We evaluated three options.
Options considered
Option A — Keep signed cookies, shrink the payload. Move everything except
user_id and issued_at into a per-request
database lookup. Cheapest change,
but adds a DB round trip to every authenticated request (~4,000 rps peak) and
does not solve revocation.
Option B — Redis-backed sessions. Cookie carries only an opaque session id.
Session body lives in Redis with a 14-day TTL. Revocation is a
DEL. Adds an
external dependency to the auth path.
Option C — Database-backed sessions. Same shape as B, but Postgres instead
of Redis. Reuses infrastructure we already operate and back up. Higher latency
(~6ms vs ~0.4ms measured on a spike) and adds write load to the primary.
Decision
Adopt Option B. A single ElastiCache Redis node in
us-east-1, cache.r6g.large,
with the session body serialised as JSON.
Rationale
Revocation is the requirement that actually forced this, and B is the only
option that makes it a constant-time operation. Latency matters on the auth
path and Redis is an order of magnitude faster than Postgres for this access
pattern. We already run Redis for the rate limiter, so the operational surface
is not new to the team.
Consequences
- Auth now depends on Redis availability. If Redis is unreachable, users cannot
authenticate. We accept this.
- Session cookie drops from ~3.1KB to 64 bytes, reducing average request size
by roughly 12%.
- Estimated cost: $190/month for the node. We expect a 98% cache hit rate based
on the rate limiter's observed behaviour.
- Migration is a dual-read period of 14 days (the old cookie TTL), after which
cookie-carried sessions are rejected.
Implementation notes
- Session id: 128-bit random, base64url encoded.
- TTL refreshed on each request (sliding expiry).
-
Session body includes
user_id,org_id,roles,impersonator_idwhen an
admin is acting as a customer, and a csrf_token.
- No changes to the login flow itself; only where the session body is stored.
Rollout
Week 1: dual-write, read from cookie. Week 2: dual-write, read from Redis with
cookie fallback. Week 3: Redis only. Week 5: remove cookie-session code path.
Open questions
- Do we need a second Redis node? A single node has no failover, but adding a
replica roughly doubles cost and the team has not operated Redis replication
before.
-
Should
roleslive in the session at all, or be re-fetched per request so a
permission change takes effect immediately?