Redis maxmemory policy is the rule Redis follows when the cache reaches its memory limit. It decides whether Redis rejects new writes or removes keys based on least recently used, random, TTL-based, or no-eviction behavior. In Azure, this setting is important because applications often assume cached data can disappear safely, but some teams accidentally store business state in Redis. The right policy depends on whether the workload values successful writes, predictable misses, or strict protection against silent data loss.
Redis maxmemory policy controls how Redis responds when cache memory is full. Azure Cache for Redis exposes policies such as volatile-lru, allkeys-lru, volatile-random, allkeys-random, volatile-ttl, volatile-lfu, allkeys-lfu, and noeviction so teams choose whether Redis evicts keys or rejects writes under pressure.
In Azure architecture, maxmemory policy is a data-plane behavior exposed through the managed cache configuration. Azure Resource Manager, CLI, and deployment templates can set or report the policy, while Redis applies it during runtime memory pressure. The policy interacts with SKU capacity, reserved memory, fragmentation, clustering, TTL usage, persistence, and application retry logic. Azure Monitor surfaces the operational symptoms through used memory, evictions, server load, and cache-miss metrics, but the actual result is experienced by Redis clients as evicted keys or failed writes.
Why it matters
The maxmemory policy is a small setting with outage-sized consequences. A noeviction policy protects keys from automatic removal, but write-heavy applications can start failing when memory fills. An allkeys policy keeps writes moving, but it may remove keys that were never meant to be disposable. Volatile policies only evict keys with expiration, which is useful when TTL discipline is strong and dangerous when it is not. This setting forces architects to be honest about Redis data semantics. If the workload cannot tolerate eviction, it needs more capacity, persistence, or a different data store. If it can tolerate eviction, the policy should match how users experience misses.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
In Azure Cache for Redis Advanced settings, maxmemory-policy appears with values such as noeviction, allkeys-lru, volatile-lru, allkeys-random, volatile-random, and volatile-ttl during production memory pressure events.
Signal 02
In Azure CLI output, redisConfiguration.maxmemory-policy shows the active memory-pressure behavior that Redis applies when the cache reaches its configured memory limit during production incidents.
Signal 03
In Azure Monitor, eviction count, used memory percentage, cache misses, and server load reveal whether the policy is affecting users or backend systems under load.
✦
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 or LFU behavior when every key is disposable and the real risk is stale data blocking hot cache entries.
Use volatile policies when only TTL-backed keys should be eligible for eviction and nonexpiring control keys must not disappear.
Keep noeviction for correctness-sensitive caches where failed writes are safer than silently evicting state.
Compare policies during Azure Managed Redis migration, especially where modules, clustering, or geo-replication can lock eviction behavior.
Reduce cost by fixing TTL and value-size issues before scaling to a larger Redis SKU.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Exam platform prevents write failures during national testing week
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
An education assessment provider used Redis for temporary student sessions and answer-progress hints. During mock exams, noeviction caused write failures when unused practice-session keys filled the cache.
🎯Business/Technical Objectives
Keep active exam sessions responsive during peak testing windows.
Prevent stale practice data from blocking new writes.
Avoid scaling the cache before fixing expiration discipline.
Document which keys were safe to evict.
✅Solution Using Redis maxmemory policy
The architecture team classified Redis prefixes into active-session, practice-session, exam-lock, and analytics-hint groups. Exam locks and official answers were moved to durable services, leaving Redis to hold rebuildable session and hint data. Azure CLI captured the existing noeviction setting, SKU, reserved memory values, and memory metrics for the change record. Developers added TTLs to practice-session keys and changed the policy to allkeys-lru after load testing with realistic student traffic. Azure Monitor alerts watched evictions, cache misses, write latency, and database read pressure. The rollback command and expected metric thresholds were included in the exam-week runbook.
📈Results & Business Impact
Peak write failures dropped from 1,800 per hour to fewer than 40 per hour.
Used memory stabilized below 78 percent during the national exam window.
The team avoided a planned SKU upgrade, saving about 18 percent for the quarter.
No official answer or exam-lock record was lost because those records no longer lived in Redis.
💡Key Takeaway for Glossary Readers
Maxmemory policy works best after teams decide which cached data can disappear and which data belongs somewhere durable.
Case study 02
Airline pricing API improves hit ratio with frequency-aware cache behavior
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
An airline pricing group cached fare rules and promotion eligibility for thousands of routes. Random eviction removed popular route data, causing database spikes during morning booking traffic.
🎯Business/Technical Objectives
Protect frequently requested fare data from unnecessary eviction.
Reduce database reads during booking peaks.
Keep cache memory within the existing Azure budget.
Create a repeatable policy comparison process.
✅Solution Using Redis maxmemory policy
Engineers compared allkeys-random, allkeys-lru, and allkeys-lfu behavior using production-like route popularity data. Azure CLI exported the current Redis configuration across regional caches, while Azure Monitor supplied eviction, hit ratio, server load, and backend query trends. The team moved rare route promotions to shorter TTLs and selected a least-used policy that favored commonly accessed fare rules. Deployment scripts applied the policy consistently across test and production after change approval. Dashboards then compared hit ratio and database reads by route family, making it clear whether the policy improved real customer traffic rather than only synthetic benchmarks.
📈Results & Business Impact
Cache hit ratio improved from 71 percent to 86 percent during peak booking hours.
Database read volume for fare rules fell by 29 percent.
No cache SKU increase was required for the next two seasonal promotions.
Policy drift across four regional caches was eliminated by the scripted rollout.
💡Key Takeaway for Glossary Readers
Choosing the right memory policy can improve performance and cost when it reflects actual access patterns, not a generic default.
Case study 03
Industrial IoT service stops evicting safety telemetry markers
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A factory IoT platform cached recent sensor readings, alert deduplication markers, and maintenance hints. Eviction sometimes removed deduplication markers, causing duplicate safety notifications to flood technicians.
🎯Business/Technical Objectives
Stop eviction from weakening alert deduplication.
Keep high-volume sensor caches inexpensive and disposable.
Reduce duplicate safety notifications by at least 60 percent.
Separate correctness-sensitive keys from cache-only telemetry.
✅Solution Using Redis maxmemory policy
Architects split the design into two Redis workloads. High-volume sensor snapshots stayed in an evictable cache with short TTLs and allkeys-lru behavior. Alert deduplication markers moved to a smaller protected cache using noeviction, stronger alerts on memory pressure, and a runbook for scale-up. Azure CLI documented the policy and SKU for each cache, and IaC templates prevented the two values from drifting. Application code tagged prefixes so operators could connect evictions to telemetry snapshots rather than safety controls. Azure Monitor alerts watched memory pressure on the protected cache because noeviction would create write errors if capacity planning failed.
📈Results & Business Impact
Duplicate technician notifications dropped 74 percent within the first month.
The telemetry cache stayed on its existing SKU despite higher sensor volume.
The protected cache generated two early memory alerts before write failures occurred.
Incident reviews became clearer because eviction metrics applied only to disposable telemetry data.
💡Key Takeaway for Glossary Readers
A single Redis maxmemory policy is rarely enough when a workload mixes disposable cache data with correctness-sensitive markers.
Why use Azure CLI for this?
With ten years of Azure operations behind me, I prefer Azure CLI for maxmemory policy because it removes ambiguity during a high-pressure incident. The portal can show the setting, but CLI lets me query it, export it, compare it across environments, and change it through an approved script with review history. I can pull the policy next to reserved memory, SKU, shard count, and Azure Monitor metrics, then decide whether the problem is configuration, capacity, or application behavior. CLI is also safer for governance because a pipeline can block unapproved policies on production caches before drift becomes an outage. quickly.
CLI use cases
Query the current maxmemory policy across caches before a memory-pressure incident review or architecture standard update.
Update the policy through a reviewed command or pipeline instead of relying on portal-only configuration changes.
Compare policy, reserved memory, SKU, and eviction metrics to separate capacity problems from application key hygiene problems.
Inventory Enterprise database eviction policies before creating active geo-replication or module-enabled databases.
Export policy evidence for compliance reviews that require documented cache behavior under memory pressure.
Before you run CLI
Confirm subscription, resource group, cache name, and whether the instance is Azure Cache for Redis or Azure Managed Redis.
Use Reader permission for inspection and a tightly controlled role for updates because policy changes can affect live writes immediately.
Check current used memory, evictions, backend load, and active incidents before changing the setting during business hours.
Verify the chosen policy is valid for the service tier, database type, and any module requirements such as NoEviction.
Capture before-and-after JSON output so rollback, change records, and post-incident review all use the same evidence.
What output tells you
redisConfiguration.maxmemory-policy identifies the active policy for Azure Cache for Redis and shows whether Redis evicts keys or rejects writes.
Enterprise evictionPolicy identifies the database-level behavior on Azure Managed Redis or Redis Enterprise style databases.
Reserved memory fields show whether Azure has headroom for fragmentation, replication, and background work before application data fills memory.
SKU and capacity fields explain whether the workload has enough memory or needs a scale-up, clustering change, or data cleanup.
Metric output connects policy choices to real symptoms such as evictions, misses, high server load, or rising backend latency.
Mapped Azure CLI commands
Redis maxmemory policy CLI Commands
direct
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 show --name <cache-name> --resource-group <resource-group> --query "redisConfiguration.{maxmemory-reserved:maxmemory-reserved,maxfragmentationmemory-reserved:maxfragmentationmemory-reserved}"
az redisdiscoverDatabases
az redisenterprise database show --cluster-name <cluster-name> --resource-group <resource-group> --query "{evictionPolicy:evictionPolicy,provisioningState:provisioningState}"
az redisenterprise databasediscoverDatabases
az redisenterprise database update --cluster-name <cluster-name> --resource-group <resource-group> --eviction-policy AllKeysLRU
az redisenterprise databaseconfigureDatabases
Architecture context
In a production cache architecture, maxmemory policy should be designed alongside TTL rules, capacity planning, and failure behavior. I expect teams to classify Redis data into disposable, rebuildable, and should-not-be-in-Redis categories before choosing a policy. For session caches and recommendation hints, allkeys-lru or allkeys-lfu can be reasonable because users can recover from misses. For queues, locks, financial state, or idempotency records, eviction can create correctness bugs and noeviction may reveal pressure sooner. Azure reserved memory and fragmentation settings also matter because Redis needs headroom for failover, replication, and background work. The policy is not a substitute for right-sizing or data hygiene.
Security
Security impact is indirect because maxmemory policy does not grant access or encrypt data. The risk appears when eviction changes application behavior in ways attackers can exploit. If security tokens, rate-limit counters, abuse-detection flags, or idempotency records are stored in Redis and evicted unexpectedly, controls may weaken. Access to change the policy should be limited to approved operators through Azure RBAC and change management. Protect the management plane with least privilege, log configuration updates, and avoid storing secrets or durable authorization state in an evictable cache. Network isolation and TLS still matter because clients can amplify memory pressure intentionally or accidentally.
Cost
Maxmemory policy has an indirect but measurable cost path. A strict noeviction setting can reveal the need for a larger cache SKU sooner, while a permissive eviction policy can hide poor data hygiene until backend databases absorb more cache misses. Volatile policies require disciplined TTLs; otherwise teams pay for memory that stale keys occupy. Enterprise or clustered deployments may cost more if the policy choice increases required headroom. FinOps reviews should compare policy, used memory trends, eviction counts, and backend database spikes before approving a scale-up. Sometimes the cheapest fix is deleting unbounded keys, not buying more cache. and staffing.
Reliability
Reliability depends on whether the selected policy matches the workload's tolerance for missing keys or failed writes. Noeviction can protect cached entries but turn memory pressure into write errors that break application flows. Eviction policies can preserve availability for writes while increasing cache misses, database load, and user-facing latency. Volatile policies become unreliable when developers forget TTLs. Operators should combine policy selection with alerts on used memory, evictions, rejected connections, server load, and backend saturation. Test failover and restart scenarios too, because memory headroom and hot-key behavior can change after node movement or cache warm-up. Run controlled tests before changing production memory behavior.
Performance
Performance changes when Redis reaches memory pressure. Eviction policies keep writes moving but can increase misses and push traffic back to databases or APIs. Noeviction avoids automatic removals but can make write paths fail, retry, and add latency under load. LRU, LFU, random, and TTL-based policies produce different hit-ratio patterns depending on access distribution and TTL discipline. Azure Monitor metrics help operators see the tradeoff: rising evictions, lower hit ratio, higher server load, and backend latency. Tune the policy with representative traffic rather than relying on a default chosen before the application matured. Watch retry storms after policy changes too.
Operations
Operators inspect maxmemory policy during capacity reviews, incident triage, migration planning, and release gates. Azure CLI can show the configured policy, reserved memory settings, SKU capacity, and Enterprise database eviction policy. Azure Monitor provides the evidence that policy behavior is happening, especially evictions, used memory percentage, cache misses, and server load. Runbooks should document why the policy was chosen, which prefixes are safe to evict, and what rollback means. Changing the policy should be treated as production-impacting because it can immediately alter write behavior, latency, and downstream database load. I also keep rollback commands ready for emergency review and document decisions clearly.
Common mistakes
Choosing allkeys eviction while storing locks, idempotency markers, or business state that should never disappear automatically.
Selecting noeviction without alerting on memory pressure, which turns a predictable capacity issue into sudden write failures.
Assuming volatile policies work safely when developers have not applied TTLs consistently across important key prefixes.
Changing the policy during an incident without capturing current memory, eviction, and backend load metrics for rollback decisions.
Treating the policy as a cost-control replacement for deleting stale keys or resizing an undersized cache.