Page 9 - Redis

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.

Every Redis access costs a network round trip, even when the value has not changed since the last query. Client-side caching flips this principle around: frequently read values move into the application's local memory, and Redis actively reports through the tracking protocol as soon as a cached key changes. That eliminates the round trip for many reads entirely, without the application risking stale data. How the tracking protocol works technically, where broadcasting and default mode differ, and where the practical limits lie, is what this article covers.

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.

A Magento Docker stack consists of at least five services: PHP-FPM, Nginx, MySQL, Redis, and OpenSearch. Add RabbitMQ for message queues and Varnish for full page caching. How these services are correctly networked, persisted, and started in the right order determines stability and maintainability.

PHP-FPM processes every request in its own synchronous worker process, which only becomes available for the next request once the current one has fully completed. Blocking Redis commands such as BLPOP, BRPOP, or XREAD BLOCK actively wait for an event before returning, which fundamentally clashes with this model: a single such call inside a Magento controller or plugin can tie up an entire PHP-FPM worker for seconds or even minutes, while other visitors wait for a free worker. This article shows why these commands are problematic in web processes, where they tend to end up by accident in practice, and which alternatives for event-driven flows actually work within a synchronous PHP architecture.

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.