Redis

Ten million boolean flags, one flag per user, need just 1.25 megabytes of memory as a Redis bitmap, because every flag occupies exactly one bit instead of an entire set entry. SETBIT, GETBIT, BITCOUNT and BITOP make bitmaps the most compact tool for daily active user tracking and similar counting problems at huge user scale.

When a single Redis instance in Magento reaches its limits, two paths open up: a real Redis Cluster with sharding, or a clean separation of cache, session and full page cache onto dedicated Redis instances. This article shows when each path makes sense and how the transition actually works.

Redis keyspace notifications turn every write operation and every key expiry into a Pub/Sub event that any number of consumers can react to. Instead of running expensive polling against the dataset, an application subscribes to exactly the changes it cares about and builds reactive architectures without an additional message queue.

Diskless replication promises faster replica synchronization by streaming the RDB snapshot directly over the network socket instead of routing it through an intermediate file on disk. But this advantage comes with real limits that need to be understood before production use, so a network hiccup does not force a complete restart of the synchronization.

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.

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.

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.