Redis Cluster separates key placement from machine identity. A key maps to one of 16,384 fixed hash slots; cluster metadata maps those slots to primaries and their replicas. Adding a machine does not change the slot hash function. Operators redistribute slots, while clients discover the current topology and react to routing changes. ...
An append-only file records Redis mutations for recovery, but choosing AOF is not the same as promising that no acknowledged write can ever disappear. Durability depends on the fsync policy, effective configuration, storage behavior, and which failure you mean. Start with a recovery objective rather than the reassuring word “log.” ...
MULTI/EXEC prevents another client’s commands from interleaving while the queued commands execute. That alone does not protect a value read earlier in the application. If two buyers read the same stock count and later write their own calculated value, wrapping each SET in a transaction can still lose an update. ...
Delivery is not completion: schematic.
A Redis stream does not automatically track a separate cursor for every connection. Ordinary XREAD uses a position supplied by the application. A consumer group instead owns a server-side last-delivered position plus pending delivery records. Confusing those two forms of progress can make a restart skip unfinished work or replay effects already completed. ...
Redis expiration answers when a key should stop being available, not how much memory the server may consume. A deadline belongs to the key, and later commands can preserve, replace, or remove it. Reliable TTL use therefore requires testing update paths as well as the initial insertion. A successful write alone says nothing about the deadline remaining afterward. ...
RDB and AOF preserve different representations of Redis state. Choosing between them starts with two questions: how much recent data may be lost, and how long recovery may take? A persistence setting alone answers neither. You need a recoverable artifact, an understood acknowledgment policy, and a restore procedure tested against actual values. ...
A Redis process can keep a substantial resident footprint after application keys are deleted. That observation deserves explanation, but it does not by itself prove a leak or allocator fragmentation. The useful question is which bytes remain allocated, which pages remain resident, and whether that footprint threatens the actual capacity budget. ...
Redis keys are binary-safe names in a flat keyspace, not filesystem paths or schema declarations. Colons are a useful convention for separating ownership, environment, entity, and identifier. A name such as cart:prod:string:42 can explain intent, but Redis does not interpret those labels as a type check or access restriction. ...