Page 4 - Redis

Session storage looks trivial until an application scales across multiple servers and the first login vanishes right after a deploy. Redis as a centralized session store solves the scaling problem, but brings its own architecture decisions along with it, from serialization format through TTL strategy to the question of whether sticky sessions are even needed anymore.

Redis traditionally processes commands in a single thread, which prevents race conditions but only uses a fraction of the CPU power available on modern multi-core servers. KeyDB addresses exactly this point, processing network I/O and command execution across multiple threads simultaneously while positioning itself as a largely compatible alternative to the Redis protocol. This article explains how KeyDB works technically, how compatible it really is, and in which Magento operating scenarios a switch could actually pay off.

Once a Magento shop scales across several application servers with cron jobs running on each of them, the same indexer can in theory be triggered by two processes at once. Magento's built-in, database-based locking prevents that reliably within a single MySQL instance, but hits practical limits once coordination is needed across several independent cron workers with their own process management, such as containerized deployments with multiple equivalent worker pods. Redis offers itself as a fast, already-present infrastructure component for implementing distributed locks following the Redlock algorithm's principle, reliably avoiding indexer collisions.

When Redis Ltd announced in March 2024 that future versions would no longer ship under the permissive BSD license but under the Server Side Public License and the Redis Source Available License, part of the community responded by founding an independent fork. Under the umbrella of the Linux Foundation, Valkey emerged, building on the last BSD-licensed Redis codebase and developing independently ever since. For operators of existing Redis installations, including in the Magento context, this raises a concrete question: how compatible is Valkey really, and does switching make sense.

Write-through writes synchronously into both cache and database, guaranteeing consistency at the cost of extra latency. Write-back only writes to the cache and delays the database write asynchronously, saving latency but creating a real risk of data loss if the cache server fails. Which strategy fits depends on the consistency requirements of the specific data.

HyperLogLog is familiar to many Redis users for counting problems, but it only covers part of the probabilistic use cases. RedisBloom adds Bloom filters for membership tests, Cuckoo filters with delete support, and a Top-K structure for the most frequent elements, each with deliberate trade-offs between accuracy and memory usage.

Memory fragmentation occurs when the jemalloc allocator holds more physical memory than Redis actually needs for its data, and it can be measured precisely via mem_fragmentation_ratio. Anyone who understands how jemalloc manages memory blocks can configure Active Defrag deliberately and knows when a controlled restart is the better choice over live defragmentation.

RDB snapshots store the entire dataset of a Redis server as a compact binary file at fixed points in time. Anyone who understands save points, the BGSAVE fork mechanism, and copy-on-write can configure snapshot intervals so that data loss and latency spikes both stay under control, instead of relying on default values.

A poorly chosen maxmemory-policy leads either to write commands being rejected in the middle of production or to the silent loss of important data that was actually meant to persist. Understanding how Redis manages memory under pressure lets you pick the right policy deliberately instead of by accident, avoiding both outcomes reliably.

used_memory does not always drop as much as expected after deleting thousands of keys, because the underlying memory allocator becomes fragmented. Active defrag is the mechanism Redis uses to incrementally reduce that fragmentation during live operation, without causing noticeable latency spikes.