Azure Cache for Redis
Azure Cache for Redis is managed Redis: an in-memory data store for caching, session state, and pub/sub, returning data in microseconds where a database would take milliseconds. You put it in front of a slower data store or use it as a shared, fast scratch space across instances.
The defining risk is treating the cache as a source of truth. Redis is fast because it is in memory, and memory is volatile — a cache that holds the only copy of important data is a data-loss incident waiting to happen. Used as a cache, it is one of the highest-leverage services on Azure; used as a database, it is a liability.
Tiers
Tiers climb in capability and price. Basic is a single node with no SLA, for dev only. Standard adds a replicated two-node configuration with an SLA. Premium adds clustering, persistence, VNet support, and larger sizes. The Enterprise and Enterprise Flash tiers run Redis Enterprise for the highest throughput, active geo-replication, and modules, with Enterprise Flash extending capacity onto SSD.
These tiers are on a retirement path. Microsoft has made Azure Managed Redis generally available as the successor — zone-redundant by default, authenticating with Entra ID instead of access keys, and including the Enterprise features — and is retiring Azure Cache for Redis: the Basic, Standard, and Premium tiers on 30 September 2028, and the Enterprise and Enterprise Flash tiers on 31 March 2027. New caches should start on Azure Managed Redis; the tiers above remain the model to understand and to migrate from.
Use Cases
The canonical patterns are cache-aside (check the cache, fall back to the database on a miss, then populate the cache), session and token storage shared across stateless app instances, and lightweight pub/sub messaging. Each leans on Redis's speed and its role as shared state that no single application instance owns.
Clustering and Persistence
Premium and Enterprise tiers support clustering to shard data across nodes for capacity and throughput beyond a single node. Persistence (RDB snapshots or AOF logs) can write data to disk so a cache can be rebuilt after a restart — useful for warm restarts, but not a substitute for a durable database. Persistence reduces, it does not eliminate, the volatility risk.
High Availability
Standard and above run a primary-replica pair with automatic failover, and zone redundancy (Premium and Enterprise) spreads nodes across availability zones. Even so, failover can drop in-flight operations and a cold cache after restart causes a latency spike and a load surge on the backing database — so applications must tolerate cache misses gracefully.
Redis as a cache — A fast, volatile copy in front of a durable store. The correct use — tolerate misses, repopulate from the database.
Redis as the only store — Holding data that exists nowhere else. A data-loss incident waiting to happen; persistence reduces but does not remove the risk.
- Treating the cache as the source of truth — when memory is lost, so is any data that exists only in Redis.
- Standing up a new cache on a retiring Azure Cache for Redis tier instead of Azure Managed Redis, which is GA, zone-redundant by default, and Entra ID-based.
- Running the Basic tier in production — a single node with no SLA and no failover.
- Not handling cache misses gracefully, so a failover or cold start stampedes the backing database with load.
- Caching without an eviction policy or TTLs, letting the cache fill and evict unpredictably under memory pressure.
- Skipping zone redundancy on a Premium or Enterprise cache that a production SLA depends on.
- Reaching for clustering on a workload that fits a single node, adding operational complexity for no benefit.
- Start new caches on Azure Managed Redis (now GA); treat the Azure Cache for Redis tiers as a retirement path (Basic/Standard/Premium by Sept 2028, Enterprise by Mar 2027).
- Use Redis as a cache in front of a durable store, never as the only copy of important data.
- Run Standard or higher in production for replication and an SLA; reserve Basic for dev.
- Design for cache misses — repopulate from the database and protect it against a thundering herd on cold start.
- Set TTLs and an eviction policy appropriate to the workload so memory pressure is predictable.
- Enable zone redundancy on Premium or Enterprise where the SLA requires it.
- Use clustering only when capacity or throughput genuinely exceeds a single node.
Knowledge Check
What is the central risk of Azure Cache for Redis?
- Treating volatile in-memory data as a source of truth — lost memory means lost data
- It is slower than a relational database for single-key lookups under heavy concurrent load
- It cannot be replicated for high availability across nodes
- It only supports a single string data type for every value
Why must an application using a cache-aside pattern handle cache misses gracefully?
- A failover or cold start empties the cache, and ungraceful misses stampede the backing database with load
- Cache misses silently corrupt the stored database rows and leave both the cache and the backing store in a permanently inconsistent state
- Misses are billed at a higher per-operation rate than cache hits
- The Basic tier disables misses by pre-loading every key on startup
Which tier is appropriate for a production cache that needs replication and an SLA?
- Standard or higher — Basic is a single node with no SLA
- Basic, which is the recommended production default for most workloads
- Any tier, since all of them include automatic failover
- Only Enterprise Flash, which stores data on NVMe disk
You got correct