Redis gives operators fine-grained control over what happens when memory fills up. Two settings drive this behavior: the maxmemory directive, which caps how many bytes Redis is allowed to use, and the maxmemory-policy, which selects the algorithm used to free space. Redis also supports keyspace notifications, configured by the notify-keyspace-events directive in redis.conf, which publish events on a Pub/Sub channel whenever a key is created, modified, expired, or evicted. To subscribe specifically to expiration events, a client connects to a channel named like __keyevent@0__:expired, where the 0 is the database index, and listens there.
Several eviction policies are available. The default is noeviction, which simply returns write errors when memory is full rather than removing any data. volatile-lru evicts the least recently used keys among those that have a TTL set, while allkeys-lru applies LRU eviction to every key regardless of whether it has an expiration. volatile-ttl evicts the key with the shortest remaining TTL among keys that have one. For workloads where frequency matters more than recency, the LFU policies, namely volatile-lfu and allkeys-lfu, evict the least frequently used keys, again scoped by whether a TTL is present. Choosing among these policies is essentially a question of whether some keys are exempt from eviction and whether access patterns are better captured by recency or by frequency.
For durability, Redis supports two main persistence mechanisms. RDB takes point-in-time snapshots of the dataset and writes them to a file named dump.rdb at configured intervals; the default rule in redis.conf is to snapshot after 1 hour if at least 1 key changed, after 5 minutes if at least 100 changed, and after 1 minute if at least 10,000 changed. AOF, by contrast, appends every write command to a file named appendonly.aof, which is replayed at restart to rebuild the dataset. Because the AOF file can grow indefinitely, a background rewrite compacts it from the current dataset. The appendfsync setting controls how often the OS flushes AOF data to disk: the common everysec mode flushes once per second, offering a balance between durability and performance. In general, AOF with appendfsync always gives the strongest durability, while RDB may lose the last seconds or minutes of writes in the event of a crash.