A media company's ElastiCache for Redis catalog is rejecting new writes because the node is at maxmemory and maxmemory-policy is noeviction. Every catalog key can be rebuilt from the database. Which change lets new keys in by dropping cold ones?
Select an answer to reveal the explanation.
Short Explanation
A cache that refuses to forget anything eventually refuses new guests, and noeviction is that rule: a full Redis node errors on writes instead of making room. You want allkeys-lru so cold catalog keys can leave, because the database can rebuild them. volatile-lru ignores keys that have no TTL, and a replica will not accept the writes the primary is rejecting.
Full Explanation
Redis treats noeviction as a hard stop. Once used memory hits maxmemory, write commands fail and no key is removed to make room. A catalog that can be rebuilt from the database is a cache, so allkeys-lru is the policy that can evict the least recently used key even when that key has no expiration, which lets the new write succeed. A read replica does not accept writes and does not add free memory on the primary. volatile-lru considers only keys that already have a TTL, so a catalog stored without expirations still fills the node and writes still fail. A larger database instance does not change the cache node's memory limit. Caveat: allkeys-lru can drop a key a client still hoped to read, which is acceptable only when a miss is refilled from the database. Operational check: apply the parameter group on a test node, fill it, confirm a new write succeeds, and confirm a cold key is gone while a recently read key remains.