Redis can operate as a cache, a primary data store or a mixed workload. When memory reaches the configured maxmemory limit, the eviction policy determines which keys can be removed. Choosing the wrong policy can cause unexpected cache misses or, in some configurations, reject writes instead of evicting keys.
Know the policy families
allkeys-lru evicts keys based on approximated least-recently-used behavior across the keyspace. allkeys-lfu uses approximated frequency and can favor frequently accessed keys. volatile-lru and volatile-lfu consider only keys with an expiry. volatile-ttl favors keys with shorter remaining TTL. noeviction returns errors for commands that require more memory when the limit is reached.
Set a realistic memory budget
Do not allocate the entire machine’s RAM to maxmemory. Redis needs memory for process overhead, replication buffers, client output buffers, persistence operations and the operating system. Leave headroom and monitor fragmentation. A host that swaps under pressure can experience severe latency even before Redis reaches its configured limit.
Choose by data semantics
For a disposable cache where every key is recreatable, an all-keys policy may be suitable. If only explicitly expiring keys should be removed, a volatile policy may fit, but writes can fail when no eligible keys remain. Do not use an eviction policy as a substitute for backups or durability when Redis holds authoritative data.
Observe evictions and misses
Track used_memory, used_memory_peak, mem_fragmentation_ratio, evicted keys, expired keys, hit rate and command latency. A sudden rise in evictions can signal a traffic shift or an undersized cache. Correlate it with application-level cache misses and database load.
Test the failure mode
Load test with realistic key sizes and TTL distributions. Verify what the application does when a cache key disappears or Redis rejects a write. Use bounded retries and avoid stampedes by adding request coalescing or controlled refresh strategies.
Operational checklist
- Set maxmemory below physical capacity.
- Choose an eviction policy based on key semantics.
- Use TTLs intentionally and consistently.
- Monitor evictions, misses and fragmentation.
- Test behavior when the cache is full.
Redis eviction is an application architecture decision as much as a server setting. Related guides: Redis connection troubleshooting and database connection pooling.
Design and prerequisites
Choose an eviction policy from the semantics of the data, not just a benchmark. If every key is disposable and can be recomputed, an all-keys policy may be suitable. If only keys with expiry should be removed, a volatile policy may fit, but writes can fail when no eligible keys remain. A noeviction policy protects existing keys from automatic removal but returns errors when memory is exhausted. Understand how the application handles those errors before deploying the setting.
Configuration strategy
Set maxmemory below the machine’s physical capacity. Redis needs additional memory for process overhead, client buffers, replication, persistence operations and the operating system. Copy-on-write during background persistence can temporarily increase memory use. A host that swaps may suffer severe latency even when the configured limit appears reasonable. Monitor fragmentation and reserve headroom based on workload behavior, not an arbitrary percentage copied from another environment.
Security and compatibility
LRU and LFU policies are approximations, not perfect histories of every access. LRU tends to retain recently used keys; LFU can favor frequently accessed keys even if they have not been touched recently. Workloads with seasonal or bursty access may behave differently under each policy. Test representative key distributions and request patterns, and compare hit rate, eviction count and backend load rather than assuming one policy is universally best.
Testing and validation
TTL strategy affects eligibility and application behavior. Expiring keys can disappear at any time after their TTL, so application code must handle cache misses safely. Use jitter to avoid large groups of keys expiring simultaneously. For expensive cache fills, use request coalescing or locks with bounded waits to prevent a thundering herd. Do not use very long TTLs as a substitute for invalidation when the underlying data can change.
Monitoring and diagnosis
Monitor used_memory, peak memory, evicted_keys, expired_keys, hit rate, command latency and fragmentation. A sudden eviction increase may indicate a traffic shift, a leak in key creation or a cache size that no longer matches the working set. Correlate Redis metrics with database query volume and application cache-miss rates. If the backing database becomes overloaded after eviction, reduce traffic or restore capacity rather than merely increasing retries.
Operations and maintenance
Separate disposable cache data from durable application records where possible. If Redis holds authoritative state, define persistence, replication, backup and restore procedures independently of the eviction policy. Test behavior when the cache is full, when Redis rejects writes and when a key disappears between read and update. Use idempotent operations and clear error handling. Eviction should be an intentional cache-management decision, never the only protection against data loss.
Operational handover and review
Before handing this implementation to an operations team, document the configuration owner, supported versions, dependency map and escalation path. Include the commands or dashboard views needed to verify normal operation, along with expected values and known limitations. Store configuration in version control, review changes through the normal deployment process and keep a tested rollback procedure. Schedule periodic reviews because upstream components, security requirements and workload patterns change. A short runbook should explain how to identify a failed component, what evidence to collect, which actions are safe to retry and when to escalate. Test that runbook during a maintenance exercise rather than waiting for an outage. Finally, measure the result against a baseline: reliability improvements should be visible in error rates, latency, resource consumption, recovery time or reduced manual work. This makes the implementation maintainable after the original developer has moved to another project.
Change management and production verification
Create a controlled change record for every production adjustment. Record the current value, intended value, reason, approver and expected impact before changing the live configuration. Use a staging environment or a representative test fixture to verify behavior, and compare the result against a known baseline. Keep rollback instructions beside the change record, not in an engineer’s private notes. If the change affects a shared service, coordinate the maintenance window with its consumers and define how they will report regressions.
Service-level observability
Build operational dashboards around outcomes rather than configuration alone. Track the service-level indicators that show whether the system is working: request success, latency, queue delay, resource pressure, error counts and recovery time. Add component-specific metrics where they help explain a failure, but avoid collecting high-cardinality labels that make monitoring expensive or unstable. Define alert thresholds with an owner and a response action. An alert that has no documented next step will eventually be ignored.
Failure testing and recovery
Test failure modes before declaring the work complete. Simulate a dependency outage, an invalid input, a restart during active work and a resource limit being reached. Confirm that the system fails safely, preserves recoverable state and produces useful logs. Verify that retries are bounded and that repeating an operation does not create duplicate side effects. Capture the observed behavior in a runbook so the next operator can distinguish a transient issue from a configuration defect.
Ongoing review
Review the design after the first production cycle. Compare expected and actual resource use, support incidents, maintenance effort and user impact. Remove temporary exceptions that are no longer required, update version pins deliberately and check upstream release notes before upgrades. Re-run the original validation suite after a dependency or runtime change. A technical implementation should remain understandable to a new engineer, so document trade-offs, known limitations and the reasons behind non-obvious settings.
Apply this review specifically to Redis Eviction Policies: Choose maxmemory Rules for Cache Workloads: confirm the supported runtime and component versions, validate the behavior with a representative workload, and retain evidence from the test. Do not treat a successful configuration reload as proof that the user-facing workflow is healthy. Verify the end-to-end result from the same network path and identity used by the production application.
