A Redis eviction policy is the rulebook Redis follows when the cache is full. It answers a practical question: if memory runs out, which keys should go first? Some policies remove only keys with TTLs, some can remove any key, some prefer least recently used keys, and noeviction refuses new writes instead. The policy is not a magic performance setting. It must match what the application stores, how keys expire, and whether losing certain cached entries is safe for users.
A Redis eviction policy is the configured maxmemory rule that decides which keys are eligible for removal when Redis needs memory. Azure supports policies such as volatile-lru, allkeys-lru, random, TTL-based, LFU, and noeviction depending on Redis service, tier, and database configuration.
In Azure, the Redis eviction policy appears in cache or database configuration, usually as maxmemory-policy for Azure Cache for Redis or evictionPolicy for Redis Enterprise style databases. It belongs to the data-plane behavior but is configured through control-plane operations, templates, CLI, or portal settings. The policy interacts with TTL strategy, memory reservations, SKU capacity, clustering, modules, active geo-replication limits, and application fallback design. It is reviewed alongside used memory percentage, evicted key metrics, cache hit ratio, and backend capacity.
Why it matters
The eviction policy matters because it encodes the application’s tolerance for data loss under pressure. The default volatile-lru behavior is safe only when the keys that can be removed actually have TTLs. If developers forget expirations, Redis might refuse writes or protect the wrong data. If allkeys policies are used carelessly, important coordination state might disappear. A good policy turns memory pressure into predictable cache misses; a bad one turns it into confusing outages. Teams should choose the policy during design, revisit it after traffic growth, and document why the selected behavior fits each key family. That documentation prevents risky default-driven decisions.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
The Azure portal Advanced settings page shows maxmemory policy values such as volatile-lru, allkeys-lru, volatile-ttl, noeviction, and LFU options for the cache under review. safely
Signal 02
CLI output from az redis show or az redisenterprise database show exposes the configured policy beside SKU, database, region, and provisioning state for review. later
Signal 03
Bicep or ARM templates show redisConfiguration maxmemory-policy values, making policy drift visible during infrastructure-as-code reviews and deployment comparisons across environments and subscriptions. for review
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Choose allkeys-lru for read-through caches where every value can be rebuilt from a durable backend.
Use volatile policies when only TTL-marked keys should be candidates for removal during memory pressure.
Select noeviction when silent key loss is worse than application-visible write failures.
Review policy compatibility before enabling modules, clustering, Enterprise databases, or active geo-replication.
Compare production and staging policy drift after unexplained cache misses, write failures, or backend surges.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
News personalization service chooses LFU behavior for trending stories
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A digital news publisher cached article recommendations and trending-topic scores in Redis. The default policy kept some stale but recently touched keys while evicting valuable high-frequency recommendation results.
🎯Business/Technical Objectives
Keep homepage recommendation latency below 200 milliseconds during breaking news.
Preserve frequently accessed recommendation keys through short traffic spikes.
Avoid silently evicting editorial safety flags stored with TTLs.
Document why the selected policy matched each key family.
✅Solution Using Redis eviction policy
The architecture team separated Redis keys into recommendation results, trend counters, and editorial safety flags. They moved safety flags to a durable configuration store and kept only disposable copies in Redis. In staging, operators compared volatile-lru, allkeys-lru, and LFU behavior using replayed traffic from a major news day. Azure CLI captured maxmemory-policy settings before and after each test, while Azure Monitor tracked evicted keys, hit ratio, and backend recommender calls. The team selected allkeys-lfu for the recommendation cache because repeated access mattered more than recency during developing stories.
📈Results & Business Impact
Homepage p95 latency during breaking-news drills improved from 480 milliseconds to 170 milliseconds.
Recommendation backend calls fell by 42 percent because high-frequency keys stayed hot longer.
Editorial safety flags were removed from eviction risk by moving authoritative state elsewhere.
Policy evidence was added to the deployment checklist for every Redis environment.
💡Key Takeaway for Glossary Readers
A Redis eviction policy should reflect real key behavior, not just the default value that appeared during provisioning.
Case study 02
Subscription billing platform exposes unsafe cache writes with noeviction
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A subscription billing SaaS used Redis to hold short-lived invoice calculation state. Memory pressure under allkeys-lru occasionally removed in-progress calculation keys and caused duplicate manual reviews.
🎯Business/Technical Objectives
Prevent silent loss of in-progress invoice calculation state.
Make memory exhaustion visible through controlled write failures.
Reduce manual finance reviews caused by missing Redis keys.
Prove whether Redis or the billing database owned authoritative state.
✅Solution Using Redis eviction policy
Engineers classified invoice keys as coordination state, not disposable cache data. They changed the nonproduction Redis eviction policy to noeviction and ran month-end billing simulations. The test surfaced clients that wrote unbounded intermediate keys and failed to clean them after invoice completion. The team moved durable invoice state to Azure SQL, shortened Redis TTLs for scratch keys, and kept noeviction for the narrow coordination database. CLI scripts recorded the policy, SKU, and provisioning state for each environment, while alerts watched rejected writes and used memory percentage.
📈Results & Business Impact
Duplicate manual review cases dropped by 58 percent after unsafe state was moved out of Redis.
Month-end simulation exposed three client defects before the next production billing run.
Rejected write alerts appeared 20 minutes before user impact in the final load test.
Redis capacity spend stayed flat because TTL cleanup removed the real pressure source.
💡Key Takeaway for Glossary Readers
Noeviction can be the right policy when silent key loss is more dangerous than making memory pressure obvious.
Case study 03
Online learning platform standardizes policy across course environments
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
An online learning platform ran separate Redis caches for course catalogs, quiz hints, and classroom collaboration. Different teams chose different policies, making incidents hard to compare and troubleshoot.
🎯Business/Technical Objectives
Create one approved policy pattern for each Redis workload class.
Reduce environment drift between development, staging, and production.
Keep quiz collaboration state out of disposable cache paths.
Improve incident diagnosis when cache misses or write failures appear.
✅Solution Using Redis eviction policy
The platform group inventoried every Redis cache with Azure CLI and exported maxmemory policy, SKU, tags, and owner. They defined three patterns: allkeys-lru for catalog read-through caches, volatile-lru for time-boxed quiz hints, and noeviction for a small collaboration cache that surfaced write pressure. Bicep templates were updated with explicit redisConfiguration values instead of relying on defaults. Monitoring workbooks grouped evicted keys, rejected writes, and hit ratio by workload class. Teams had to document key families and TTL expectations before receiving an exception to the baseline.
📈Results & Business Impact
Policy drift across 26 Redis caches fell from 35 percent to zero within two release cycles.
Average cache incident triage time dropped from 90 minutes to 28 minutes.
Collaboration data loss complaints stopped after state moved to a noeviction-backed design.
Backend surge events during course launches declined by 31 percent.
💡Key Takeaway for Glossary Readers
Standardizing eviction policy by workload type makes Redis behavior predictable without pretending every cache stores the same kind of data.
Why use Azure CLI for this?
Azure CLI is useful for eviction policy because policy drift is easy to miss in the portal. I use CLI to pull the current policy from every cache, compare it with environment baselines, and update it only after change approval. CLI gives an audit-friendly record of exactly which resource changed, which subscription it lived in, and which value was applied. That matters because policy changes can create silent data loss, write failures, or backend load. With ten years of Azure operations behind me, I would rather review a JSON diff than trust a screenshot.
CLI use cases
Inventory all Redis caches and report which maxmemory policy each production workload is using.
Update a nonproduction cache to test allkeys-lru, LFU, or noeviction behavior under synthetic memory pressure.
Compare Terraform, Bicep, and live CLI output to detect policy drift before a release.
Capture policy, SKU, tags, and region as evidence before changing memory behavior in production.
Check Enterprise database evictionPolicy values when active geo-replication or modules impose policy restrictions.
Before you run CLI
Confirm subscription, resource group, cache name, cluster name, database name, and service family before reading or updating policy values.
Use JSON output and read-only show commands first so the existing policy, SKU, and region are documented before any mutation.
Validate that your identity has update rights and that the change ticket explains destructive risk, cost risk, and expected cache behavior.
Know whether the selected service supports the requested policy, especially for Enterprise, Flash, modules, and geo-replicated configurations.
Coordinate with application owners because changing policy can turn memory pressure into cache misses, write errors, or backend load.
What output tells you
The maxmemory-policy or evictionPolicy value identifies which key population Redis can remove under pressure.
SKU and database properties show whether the selected policy is valid for the current tier and modules.
Provisioning state tells you whether a policy update is still applying, failed, or ready for workload testing.
Resource ID, tags, and location connect the policy evidence to the correct environment and owner.
Metric output after the change proves whether eviction, write errors, cache misses, or latency changed.
Mapped Azure CLI commands
Redis eviction policy CLI Commands
adjacent
az redis show --name <cache-name> --resource-group <resource-group> --query "redisConfiguration.maxmemory-policy"
az redisdiscoverDatabases
az redis update --name <cache-name> --resource-group <resource-group> --set "redisConfiguration.maxmemory-policy"="allkeys-lru"
az redisconfigureDatabases
az redis create --name <cache-name> --resource-group <resource-group> --location <region> --sku Standard --vm-size c1 --redis-configuration @config_maxmemory.json
az redisprovisionDatabases
az redisenterprise database show --cluster-name <cluster-name> --resource-group <resource-group> --query "evictionPolicy"
az redisenterprise databasediscoverDatabases
az redisenterprise database update --cluster-name <cluster-name> --resource-group <resource-group> --eviction-policy AllKeysLRU
az redisenterprise databaseconfigureDatabases
Architecture context
An Azure architect should connect the eviction policy to the workload’s data model, not simply copy a default from a sample. I want to see key classes, TTL expectations, approximate memory footprint, and a stated position on whether non-expiring keys are allowed. For read-through caches, allkeys-lru or LFU can make sense because any item can be rebuilt. For session-like or coordination data, noeviction or a safer TTL-specific policy may expose pressure earlier. The design also needs capacity alarms, backend surge planning, and evidence that active geo-replication or module restrictions do not conflict with the selected policy. Review this choice during every capacity redesign.
Security
Security impact is indirect because an eviction policy does not grant access by itself. The risk appears when security-sensitive keys are treated like disposable cache data. Losing rate-limit counters, replay-protection markers, authorization hints, or risk-scoring keys can weaken controls during exactly the traffic spikes attackers may exploit. Limit who can update the policy through Azure RBAC and change control. Keep encrypted client protocols, private endpoints where appropriate, and careful Redis ACL or access-key handling. Security reviews should ask whether any key family supports authentication, fraud control, throttling, or audit workflows before accepting an eviction policy. Include these keys in abuse-case reviews.
Cost
Cost impact is indirect but important. A poor eviction policy can hide under-sized capacity by constantly deleting useful keys, which drives more database reads, compute recomputation, and support incidents. A noeviction policy might avoid silent data loss but cause write failures that require larger cache tiers sooner. Allkeys policies can reduce pressure without immediate scaling, but they may increase backend load if hot keys churn. FinOps review should compare policy changes with SKU cost, database egress, Log Analytics ingestion, and engineering time. Sometimes better TTL design saves more money than a bigger Redis instance. Policy evidence should accompany each scaling request.
Reliability
Reliability impact is direct because the eviction policy defines failure behavior under memory pressure. Volatile policies depend on TTL hygiene; allkeys policies depend on the application being able to rebuild any missing key; noeviction protects data at the cost of write failures. Reliable teams test the selected policy with realistic key mixes and memory saturation, not empty demo caches. They alert on used memory percentage before eviction starts, track evicted keys, and document which services absorb cache misses. Replication and zones keep nodes available, but they do not fix a policy that removes the wrong data. Test it before a production traffic spike.
Performance
Performance impact depends on how well the policy preserves the keys that matter most. LRU and LFU policies can keep frequently used data hot, but only if key sizes and access patterns are understood. TTL-only policies can leave memory stuck with non-expiring keys, causing write failures or inefficient churn. Noeviction avoids unexpected key removal but can slow workflows through application errors and retries. Performance testing should combine realistic reads, writes, expirations, and large values. Track p95 latency, cache hit ratio, evicted keys, rejected writes, and backend response time after every policy change. Tune with traffic replay, not guesswork alone. Compare results before approving production.
Operations
Operators manage eviction policy through configuration inventory, change tickets, metrics, and workload reviews. They inspect the current policy, compare it with approved baselines, and validate that key prefixes actually have TTLs when volatile policies are selected. During incidents, they check whether evictions, rejected writes, or backend spikes match the configured behavior. A controlled change records the cache name, database, region, SKU, previous policy, new policy, and expected user impact. After the change, operators monitor latency, hit ratio, evicted keys, write errors, and database load to confirm the policy improved behavior. They should also keep a signed baseline so emergency edits are obvious later.
Common mistakes
Using volatile-lru while important keys have no TTL, then wondering why memory pressure produces write failures.
Switching to allkeys-lru without confirming the application can rebuild every evicted value safely.
Ignoring active geo-replication, module, or tier restrictions that constrain available eviction policies.
Treating policy as a one-time deployment choice instead of reviewing it after workload growth and key changes.
Changing production policy without measuring backend capacity for the cache misses that may follow.