Caching & Redis Highlights Summary

Every highlight bullet from the 6 pages in this section, gathered on one page and grouped by the page it came from.

How Caching Works in Node.js

• Caching trades a small, bounded staleness risk for a large latency and cost reduction
• A cache is always a second source of truth - it can disagree with the real one
• Redis is a shared, out-of-process cache, so every app instance sees the same cached value
• TTL is a blunt but honest tool - it bounds staleness without needing an invalidation trigger

Caching Basics

• Cache-aside: app reads cache, on miss loads DB, then sets cache
• Every cache key needs a TTL and invalidation owner
• Stampede protection: lock, jitter, or single-flight
• Cache errors should degrade to origin, not 500 users
• Measure hit ratio before caching more endpoints

ioredis

• One Redis client per process; reuse across requests
• Pipelines batch commands without waiting per command RTT
• Cluster mode needs key-aware operations
• TLS and password from env, not source
• Handle reconnecting and error events for observability

Session Stores

• Server-side sessions in Redis scale across API replicas
• Cookie holds session id only - not user data
• connect-redis pairs with express-session
• Set secure, httpOnly, sameSite on session cookies
• TTL sliding refresh on each authenticated request

Distributed Locks

• Locks coordinate workers - not a substitute for transactions
• Always set TTL - processes crash without unlock
• Hold locks for milliseconds to seconds, not minutes
• Fence tokens prevent stale lock holders writing
• Prefer idempotency and DB constraints when possible

Caching Best Practices

• Document TTL and invalidation owner per cache key family
• Redis failure degrades reads to origin when safe
• Never cache auth tokens or raw PII without policy review
• Monitor hit ratio, memory, and evictions
• Separate Redis for sessions/queues vs pure cache when possible