After moving to two web servers, users randomly log out. Cause: single Redis on maxmemory-policy allkeys-lru; cache evicts session:* keys under load. The team "added Redis" without choosing which role it plays in the architecture.
This scenario repeats whenever a powerful tool is deployed as a generic fix. Redis is a versatile in-memory engine — not one product with a default mode. Cache, session store and message broker share the protocol, not durability or eviction requirements.
Redis speeds what you decide to keep in memory. Misconfigured, it also speeds incidents: mass logouts, emails never sent, stale data served for hours. The prior question is therefore not "do we need Redis?" but "which job should Redis do — and with what rules when memory fills?"
Three uses — three contracts
Each use imposes a different contract between volatility, eviction and persistence.
| Use | Volatility OK | Eviction | Persistence |
|---|---|---|---|
| Object cache | Yes | LRU/LFU often | No |
| User session | No | noeviction or dedicated instance | AOF recommended |
| Job queue | No | noeviction | AOF + worker ack |
Cache — SQL query results, HTML fragments, rate limit counters. Reccomputable if gone.
Sessions — cart, PHP/Laravel/Symfony login, token blacklist. Loss = catastrophic UX.
Queue — Laravel Horizon, Sidekiq, Bull: emails, thumbnails. Loss = messages never sent.
Redis that evicts sessions to free cache space is an architecture bug, not tuning.
Integration patterns
PHP/Laravel — set SESSION_DRIVER=redis and CACHE_DRIVER=redis with two distinct connections and separate prefixes (app_session:, app_cache:).
Node — use connect-redis for express-session and ioredis for cache with explicit TTL on each key.
Workers — run consumers on processes separate from web; same Redis for the queue, horizontal worker scaling.
Cache TTL — always set a lifetime; avoid orphan keys without expiry.
For the underlying SQL layer, see MySQL for dynamic sites. If you hesitate between managed hosting and dedicated server, PaaS or server helps situate Redis in the whole stack.
Sizing and high availability
Size RAM: dataset plus twenty to thirty percent headroom, including queue spikes. No Redis swap — latency becomes explosive. For critical multi-node sessions, consider Redis Sentinel or managed offers (ElastiCache, Scaleway, OVH). Back up queues with AOF; cache can rebuild.
Compare managed Redis in our directory.
Common mistakes
Public exposed Redis — port 6379 without auth often leads to cryptomining.
Keys without namespace — staging/production collision.
*KEYS in production** — blocks the entire server.
Cache without invalidation — stale data after business update.
Queue without dead-letter — silently lost jobs.
The climax: Redis accelerates — it does not fix
Profile SQL and sessions before buying 4 GB managed Redis.
Decide and move forward without blind spots
First identify real need — multi-server session, object cache, job queue, or a combination — then separate instances and eviction policies by role. Configure authentication, bind Redis to private network and refuse public exposure. Monitor memory and evictions, and document business cache invalidation rules before considering the architecture stable.
Frequently asked questions
Is Redis required to speed up my site?
No. Start with HTTP cache, OPcache and optimised SQL. Redis matters when you need shared multi-server sessions, heavy object cache, or async job queues.
Cache and session on same Redis?
Discouraged in production: cache eviction can evict session keys. Separate instances or logical DBs with appropriate policies.
Enable Redis persistence?
For pure cache, often no. For sessions or queues, yes: AOF or managed Redis with backup.
Managed Redis or on VPS?
Choose managed if HA, backups and security patches exceed your skills. A VPS fits modest traffic with strict memory monitoring.
Redis: choose which job first — cache, session, or queue — before installing a one-size-fits-all instance.