Redis Memory Eviction Policies, Expiration Strategies, Cache Issues, Deployment Modes, and Persistence Mechanisms

0x01: Memory Eviction Policies

noeviction : Returns an error when memory limit is exceeded and does not evict any keys.

allkeys-lru : When adding a key and memory is over the limit, evicts the least recently used key among all keys using the LRU algorithm.

volatile-lru : When memory is over the limit, evicts the least recently used key among those that have an expiration time set.

allkeys-random : When memory is over the limit, randomly deletes a key from the entire keyspace.

volatile-random : When memory is over the limit, randomly evicts a key from the set of keys with an expiration time.

volatile-ttl : Evicts the key that is closest to expiration among keys with an expiration time.

volatile-lfu : Evicts the least frequently used key among those with an expiration time.

allkeys-lfu : Evicts the least frequently used key among all keys.

0x02: Expiration Strategies

Redis allows setting an expiration time for cached keys. The expiration strategy determines how Redis handles keys that have reached their timeout.

Active Expiration : Each key with an expiration creates a timer that removes the key immediately when the timeout occurs. This frees memory quickly but consumes significant CPU resources.

Lazy Expiration : A key is checked for expiration only when it is accessed; if expired, it is removed. This saves CPU but can leave many expired keys in memory.

Periodic Expiration : Redis scans a portion of the expires dictionary at regular intervals, deleting keys that have expired. This balances CPU and memory usage by adjusting scan frequency and duration.

0x03: Cache Penetration

Definition: Cache penetration occurs when requests query data that does not exist in both the cache and the database (e.g., querying an ID of -1 or a non‑existent large ID), often caused by malicious traffic and can overload the database.

Solutions:

Validate inputs at the API layer, such as authentication checks and basic ID validation (e.g., reject IDs <= 0).

When a key is missing in both cache and database, store a placeholder like key‑null with a short TTL (e.g., 30 seconds) to prevent repeated database hits.

0x04: Cache Breakdown

Definition: Cache breakdown happens when a hot key expires, and many concurrent requests miss the cache and simultaneously query the database, causing a sudden spike in load.

Solutions:

Set hot data to never expire.

Use a mutex lock to ensure only one request queries the database while others wait.

0x05: Cache Avalanche

Definition: A cache avalanche occurs when a large number of keys expire at the same time, leading to massive database queries that can overwhelm the backend.

Solutions:

Assign random TTLs to cache entries to avoid simultaneous expiration.

Distribute hot data evenly across multiple cache instances in a distributed deployment.

Set critical hot data to never expire.

0x06: Deployment Options

Standalone Mode

Master‑Slave Mode

Sentinel Mode

Cluster Mode

Redis Cluster was introduced after version 3.0; before that, proxy solutions such as Twemproxy, Codis, or Nginx could be used.

0x07: Persistence Mechanisms – RDB and AOF

RDB works like a snapshot camera for Redis memory data, creating a point‑in‑time dump saved to disk. It can be triggered manually or automatically. RDB offers fast restart but does not provide real‑time durability, making it suitable for cold backups and replication.

Advantages:

Excellent for full backups.

Faster recovery than AOF.

Disadvantages:

Cannot achieve real‑time persistence.

Potential compatibility issues across Redis versions.

AOF records every write command to an append‑only log, replaying the log on restart to restore data. It provides near‑real‑time durability (loss of at most 1‑2 seconds) but results in larger files and may cause append‑fsync blocking.

Advantages:

Data loss limited to 1‑2 seconds.

Disadvantages:

AOF files are larger than RDB files.

Potential for append‑fsync blocking.

0x08: Common Redis Business Scenarios

Caching hot data.

Implementing time‑limited business logic.

Counters.

Leaderboards.

Distributed locks.

Delayed tasks.

Pagination and fuzzy search.

Storing relationships such as likes and friendships.

Message queues.