Page 2 - Redis

Before installing yet another monitoring tool, it is worth looking at what Redis already provides out of the box: the INFO command and redis-cli alone deliver memory statistics, hit rate, replication status, and live latency measurement in enough depth to cover most operational scenarios, once you know where to look.

RDB and AOF solve the same underlying problem, losing in-memory data on a crash, with completely different tradeoffs between recovery time, data loss window, and resource demand. Anyone who understands both mechanisms and knows when combining RDB and AOF pays off makes a persistence decision that fits the actual use case, instead of relying on default values.

Caching in Symfony means more than $cache->get(). Anyone who really wants to gain performance combines multiple cache layers: APCu for ultra-fast in-process data, Redis for shared state across PHP processes, HTTP cache for complete response reuse, and keeps all three layers consistent through tag-based invalidation.

AOF persistence logs every write operation as a command in an append-only file, giving Redis a much tighter durability guarantee than plain RDB snapshots. Choosing the appendfsync strategy among always, everysec, and no directly decides how many milliseconds of latency get traded for how many seconds of potential data loss.

A single Redis instance for cache, session and full page cache without clean database separation is one of the most underrated sources of operational risk in Magento setups. This article explains why dedicated database indexes per role prevent key collisions, when separate Redis instances make sense, and how eviction policy can be configured differently depending on the role.

Once a single Redis master hits its capacity limit, replication alone is no longer enough. Redis Cluster automatically distributes data across 16384 fixed hash slots spread over multiple nodes, computes each key's assignment via CRC16, and lets hash tags give precise control over which keys must land together on the same node.

When Redis needs to remove a key under maxmemory pressure, it does not scan the entire database for the least recently used entry. Instead, it draws a small random sample and picks the seemingly best candidate from it, a deliberate trade-off between accuracy and speed that can be fine-tuned through maxmemory-samples.

Redis nodes confined to a single availability zone are powerless against the loss of that exact zone, no matter how well internal replication is configured. A well thought out distribution of masters and replicas across multiple zones significantly increases resilience, but it requires deliberate decisions about latency, network cost and the limits of cloud-managed Redis offerings.

Magento's full page cache invalidates entries through tags like cat_p_123 or cat_c_45, which are entity-scoped but not store-specific by default. In a multi-store installation with several websites, store groups, and store views, that means a change actually relevant to only a single store view, such as a store-specific price rule or an individual approval status, can still invalidate cache entries for every other store because they share the same tag namespace. Anyone running many stores needs to deliberately decide how granular tags should be, without sliding into a tag explosion with an unmanageable number of barely reused tags.

Out of the box, Redis only knows direct key access, no queries across multiple fields and no full-text search. RediSearch closes this gap by building secondary indexes directly over hashes or JSON documents, enabling filter, sort, and full-text queries without duplicating the data into a separate search system.