Page 6 - Redis

Redis Pub/Sub distributes messages in real time to all currently connected subscribers, without storing them or giving any delivery guarantee. This fire-and-forget semantic makes Pub/Sub ideal for live notifications between services, but unsuitable for anything that needs persistence or guaranteed delivery.

Synchronous systems scale up to a point, then HTTP requests grow too long, database connections pile up, and a single failing service blocks the entire system. Symfony Messenger solves exactly this problem through a clear separation of command, event and query, combined with asynchronous transports that deliver messages reliably even during system outages.

A Redis hash with three fields and a Redis hash with thirty thousand fields are stored internally in completely different ways, even though both are addressed through the same commands like HSET and HGET. Redis automatically chooses between a compact, memory-optimized listpack encoding for small collections and a classic hashtable structure for large ones, depending on configurable thresholds. Knowing this automatic switchover point makes it possible to deliberately design data models so Redis stays in the memory-efficient listpack encoding as long as possible. This article covers how the switch works technically and what practical consequences follow for memory planning.

Anyone who has stored JSON data as a plain string in Redis knows the problem: even the smallest change to a single field requires loading the entire document, deserializing it, changing it, and writing the whole thing back. RedisJSON solves this by managing JSON documents as their own native data type and allowing targeted access to individual paths through JSONPath expressions, without ever moving the whole document.

Persistence mechanisms like RDB and AOF protect against a process crash, but not against a failed disk, a deleted server, or a human mistake. A solid backup strategy for Redis copies snapshots consistently, automates retention, regularly tests restores, and keeps at least one copy outside the production infrastructure.

Sporadic latency spikes are among the most unpleasant performance problems in a Redis instance, because they can neither be reproduced with a single command nor explained by a simple load measurement. The built-in latency monitor was designed exactly for this case: it internally logs several event classes, from slow commands through fork operations to the expiry cycle of expired keys, and exposes them through the LATENCY HISTORY, LATENCY LATEST, and LATENCY DOCTOR commands. This article covers how these event classes work in detail, how the latency monitor combines usefully with the classic slowlog, and what a systematic diagnostic workflow looks like when latency problems occur only occasionally and seemingly at random.

Since Redis 6, a single password for the entire server is no longer enough as the only security model. The ACL system lets you create a dedicated user per application service with exactly the commands and key patterns that service actually needs. Predefined command categories such as @read, @write, @admin, or @dangerous make this least-privilege model practically manageable, instead of manually allowing or blocking every single one of the several hundred Redis commands. This article covers how to combine these categories sensibly, how dangerous commands like FLUSHALL or KEYS get controlled in production, and what a realistic multi-service setup looks like for a Magento store.

Anyone running an existing Redis application against a Redis Cluster for the first time almost inevitably runs into the error message CROSSSLOT keys in request don't hash to the same slot as soon as a multi-key command such as MGET, or a transaction, touches several keys at once that are spread across different hash slots. This article explains why this behavior is a deliberate design decision in Redis Cluster, how hash tags can be used deliberately to colocate related keys, and what price that solution costs in terms of restricted sharding distribution.

A publicly reachable API without rate limiting is an open invitation for brute force attacks, credential stuffing and automated data scraping. The Symfony Rate Limiter offers three different algorithms, Token Bucket, Sliding Window and Fixed Window, and can be integrated into any controller, service or event listener within minutes.

Redis has no native concept of multi-tenancy out of the box, which is why every multi-tenant setup requires a deliberate architectural decision. Three approaches are typically on the table: prefix-based namespaces within a shared database, logical databases via the classic SELECT index, or fully separate instances per tenant. All three differ significantly in isolation level, backup granularity, and scalability. This article compares the three strategies against concrete criteria and derives a practical recommendation for multi-store Magento setups, where several store views are meant to share the same cache layer.