Three Redis Roles for Cache and Sessions
Three Redis Roles for Cache and Sessions
Separate Redis roles for Magento's application cache, page cache, and sessions, running fully in memory with eviction tuned per role.
Three Redis Roles, Kept Apart
Magento asks Redis for three different jobs, and we give each one its own space: the application cache (configuration, layout and block output), the page cache for stores without Varnish in front, and customer sessions. Each role has its own database, and busier stores run three dedicated Redis instances, one per role. A burst of cache writes can then never push out a shopper's cart or login, and a cache flush never touches sessions.
Eviction Tuned per Role
The cache instances evict the least-recently-used keys when they fill up, so they stay fast without manual cleanup. The dedicated session instance only evicts sessions that have an expiry, so active shoppers keep their sessions. Memory is sized automatically from the server at provision time.
Pure In-Memory
Redis runs entirely in RAM. Disk snapshots and append-only logs are switched off, so there are no background forks and no disk writes competing with the database for I/O. Cache data rebuilds itself from live traffic.
Stateless PHP Containers
Because sessions and cache live in Redis rather than on the PHP container's filesystem, PHP containers can be rebuilt, upgraded or scaled out without logging anyone out. Redis itself is reachable only from the environment's private container network, and the PHP-to-Redis round trip stays under a millisecond. Read the Redis docs for the database layout and how to run dedicated instances.
- Three roles: application cache, page cache, and sessions
- Dedicated instance per role on busier stores
- Session-safe eviction on the session instance
- Memory sized automatically from the server
- Pure in-memory: no snapshots, no disk writes
- Private container network only

