Page 5 - Redis

Cache invalidation rightfully counts as one of the two hard problems in computer science, because every strategy forces a trade-off between consistency, implementation effort and performance. Redis offers TTL-based, explicit and tag-based invalidation, and this article breaks down which strategy actually fits which use case.

Redis Cluster deterministically assigns every key to one of 16384 hash slots, which makes horizontal scaling possible without a central coordinator. Understanding the CRC16 slot calculation, the CROSSSLOT error on multi-key commands, and the targeted use of hash tags helps you avoid distribution problems and runtime errors before they hit production.

Redis Geo-Commands do not store coordinates in a dedicated data structure but in a plain sorted set with a specially encoded score. Once you understand this mechanism, you can build radius searches, store locator features and distance calculations with a handful of commands, without a separate geo database.

A growing Redis Cluster sooner or later needs to move hash slots between nodes, take on new nodes, or remove old ones, all while the application keeps running uninterrupted. redis-cli --cluster reshard orchestrates this operation through the MIGRATING and IMPORTING state of individual slots, turning resharding into a controlled, live operation instead of a maintenance window.

Where Redis Pub/Sub irrevocably loses messages the moment no subscriber is listening, a Redis Stream stores every message durably in memory, with a sequential ID, consumer groups for distributed processing, and explicit acknowledgment via XACK. That makes Streams a lightweight alternative to Kafka for medium sized event logs.

Redis works well as a simple task queue with the LPUSH/BRPOP pattern, and Streams even deliver delivery guarantees and message history through consumer groups. But both approaches hit limits with complex routing, guaranteed ordering across many consumers, or very high message throughput, where dedicated systems like RabbitMQ or Kafka are the more robust choice.

An API endpoint without rate-limiting is an open invitation for abuse, whether from misbehaving clients, aggressive scrapers or targeted attacks. Redis provides INCR, EXPIRE and Lua scripts as the building blocks for fixed window, sliding window and token bucket limiters that stay correct and atomic even under heavy load.

Working tag invalidation is the basic prerequisite for the Magento full page cache to stay usable at all, without serving stale prices or stock levels. Understanding how X-Magento-Tags gets set, how Redis internally manages these tags, and why cache:clean does something fundamentally different from cache:flush lets you fix invalidation problems precisely instead of resorting to a blanket cache wipe.

Redis TTL values do not just determine when a key disappears, they directly influence system load at expiration time. Anyone who sets thousands of keys with an identical TTL risks a thundering herd effect, where all caches empty out at the same moment and flood the backend with requests. TTL jitter solves exactly this problem.

Knowing only that Redis supports LRU or LFU as an eviction strategy does not explain why the actual hit rate diverges from the theory. The approximated sampling, the logarithmic counter and the decay logic behind the scenes determine how close an eviction strategy gets to its theoretical optimum in practice.