Redis Session Store Design Prompt

You are a senior backend engineer who has run Redis-backed session stores at scale.

I will provide:
- My app framework and current session mechanism
- Session size, traffic, and login duration expectations
- Whether I run behind a load balancer

Your job:

1. **Key design**: `session:<id>` with a high-entropy random ID (never sequential). Consider a `user:<id>:sessions` set to support "log out all devices".
2. **TTL strategy**: set an absolute or sliding expiry with EXPIRE/PEXPIRE. Sliding sessions must refresh TTL on each request (EXPIRE on read) — decide idle timeout vs absolute cap.
3. **Serialization**: pick a format (JSON, MessagePack, or a Redis Hash with HSET fields). Hashes let you update one field without rewriting the whole blob and support per-field reads.
4. **Sticky vs shared**: sticky (LB affinity) keeps sessions node-local and simple but breaks on node loss; shared Redis sessions survive node failure and enable horizontal scale — recommend shared for stateless app tiers.
5. **Consistency**: avoid read-modify-write races on the session blob under concurrent requests from the same user (multiple tabs) — use Hash field updates or WATCH/Lua.
6. **Security**: rotate session ID on privilege change/login, store minimal PII, consider encrypting sensitive fields, set short TTLs for elevated sessions.
7. **Eviction safety**: session keys must NOT be silently evicted — use a policy like volatile-lru only if every session has a TTL, or isolate sessions on their own instance.
8. **Invalidation**: support single-session logout (DEL session:<id>) and all-sessions logout (iterate the user's session set).

Mark DESTRUCTIVE: FLUSHALL/FLUSHDB (logs everyone out), mass DEL of session:* , CONFIG SET maxmemory-policy to an aggressive evicting mode on a session instance.

---

Framework/session mechanism: [DESCRIBE]
Size/traffic/duration: [DESCRIBE]
Behind a load balancer: [DESCRIBE]

Why this prompt works

Session stores fail in quiet, expensive ways: silent evictions log everyone out, whole-blob writes race across tabs, and sliding TTLs never let abandoned sessions die. This prompt makes the model reason about TTL semantics, serialization tradeoffs, and the sticky-vs-shared decision explicitly instead of defaulting to a naive JSON-in-a-string design.

How to use it

1. Describe your framework and how sessions work today.
2. Give session size and login duration so TTL and format fit.
3. Say whether you use LB affinity — decides sticky vs shared.
4. Ask for the invalidation flows (single and all-device logout).

Useful commands

# Create a session as a Hash with a sliding TTL
redis-cli HSET session:abc123 user_id 42 role admin csrf tok9
redis-cli EXPIRE session:abc123 1800          # 30-min idle timeout

# Refresh TTL on each request (sliding)
redis-cli EXPIRE session:abc123 1800
redis-cli TTL session:abc123

# Track a user's sessions for "logout everywhere"
redis-cli SADD user:42:sessions session:abc123
redis-cli SMEMBERS user:42:sessions

# Invalidate
redis-cli DEL session:abc123                   # single device
redis-cli SREM user:42:sessions session:abc123

Example config

# Session instance configuration (redis.conf)
maxmemory 4gb
# Only evict keys that HAVE a TTL, never non-volatile keys:
maxmemory-policy volatile-lru
# Persistence so a restart does not drop every session:
appendonly yes
appendfsync everysec

# Enforce: every session key MUST be written with a TTL, e.g.
#   HSET session:<id> ...   then EXPIRE session:<id> 1800
# Absolute cap enforced in app: reject if session age > 12h even if idle TTL alive

Common findings this catches

• Silent evictions → users randomly logged out.
• Guessable IDs → session hijacking.
• Blob write race → lost session updates across tabs.
• Immortal idle sessions → sliding TTL with no absolute cap.
• No all-device logout → cannot revoke compromised accounts.
• No ID rotation on login → session fixation.
• No persistence → restart drops all sessions.

When to escalate

• Compliance-scoped PII in sessions — security and privacy review.
• Multi-region session sharing — reconsider architecture (edge tokens).
• Very high session churn — dedicate an instance and tune persistence.