Page 3 - Redis

The Redis cache backend replaces Magento's default file based cache with an in memory store and removes one of the most common I/O bottlenecks in production shops. Understanding env.php, Cm_Cache_Backend_Redis and the related parameters for compression, database separation and cache tags lets you tune the cache backend for catalog size and traffic instead of relying on defaults.

Every new TCP connection to Redis costs time, and with TLS enabled, that cost rises noticeably further due to the extra handshake. Connection pooling avoids repeated connection setup, but a wrongly sized pool creates new problems of its own, ranging from wait times to overloading the server with open connections.

Magento's built-in full page cache relies on unique URLs and HTML responses that get cached as a single unit and invalidated via tags. GraphQL breaks that model: a single POST endpoint, freely combinable query strings, variables, and partly personalized fields produce a wide range of different responses that can no longer be identified cleanly by a URL. Anyone running Magento headless or as an API backend for a custom frontend needs a dedicated caching layer on the query level instead. Redis is particularly well suited for this, because query results can be stored there as granular individual keys, tagged precisely, and invalidated selectively without flushing the entire cache.

Anyone planning a Redis high availability solution almost always faces the same fundamental choice: Redis Sentinel for automatic failover without sharding, or Redis Cluster for high availability with built in horizontal scaling. Both solve different problems, and picking the wrong one means either unnecessary operational complexity or an architecture that breaks down at the next growth ceiling.

Anyone who wants to observe requests per second, response times, or cart events over time quickly ends up needing a dedicated time series database. RedisTimeSeries brings exactly this data model directly into Redis, with automatic downsampling, configurable retention policies, and the same low latency Redis already offers for other data types.

Sorted Sets are usually seen as a tool for leaderboards, but they are one of the most versatile data structures in Redis. Backed by a score sorted skip list, Sorted Sets work equally well for time series data, delayed job execution and priority queues, often without any extra infrastructure beyond Redis itself.

Redis transactions queue commands with MULTI and execute them atomically with EXEC, without any other client interleaving its own commands. But anyone who assumes MULTI/EXEC behaves like a SQL transaction with rollback on runtime errors is working from a false assumption that can lead to inconsistent data in production.

Since Redis 6, RESP3 has offered a reworked version of the Redis protocol that supports significantly more structured data types than RESP2, which has been the established standard for decades. For applications that only talk to Redis through a mature client library, much of this stays invisible, but anyone writing custom serialization, wanting to use client-side caching, or simply trying to understand why certain values suddenly come back as a double instead of a string should know the practical differences. This article covers which new data types RESP3 introduces, how client library compatibility looks in practice, and what actually changes during a migration.

The cache-aside pattern moves all caching logic into the application: it checks Redis, loads from the database on a miss, and fills the cache itself. Anyone who ignores error handling, TTL values and race conditions ends up with silent inconsistencies and unnecessary database load, even though Redis is supposed to prevent exactly that.

As soon as multiple processes access the same resource, a local mutex is no longer enough. Redis offers SET NX PX as a simple locking primitive and the Redlock algorithm as an approach for multiple independent instances, but Martin Kleppmann's well known critique clearly shows the limits of this technique and when simpler locks are actually sufficient.