Microsoft Azure

Caching — Azure Cache for Redis

Run Redis on Azure without the classic failure modes — the wrong tier, a client that churns connections, memory with no headroom — and know where the service is heading.

Azure Cache for Redis is managed Redis inside your Azure estate. Interviewers seldom want cache-aside recited; they want evidence you have operated it: which tier, how clients should connect, and why timeouts happen.

An expert's office with a whiteboard of the most-asked answers by the door. One person keeping the board current is efficient; if every visitor insists on bringing their own marker, or someone pins up a fifty-page answer, the queue at the door grows even while the expert sits idle.

Key Concepts

1
The service is changing. Microsoft has announced the retirement of Azure Cache for Redis, with Azure Managed Redis — built on Redis Enterprise, with high availability on by default — as its successor. Existing caches keep running until their retirement dates, but a new design should start by evaluating Azure Managed Redis, and saying so shows you are current.
2
The tiers of Azure Cache for Redis.
    Basic       one node, no replica, no SLA. Development only.
    Standard    primary and replica with automatic failover; SLA
    Premium     clustering, RDB/AOF persistence, zone redundancy,
                geo-replication, larger and faster nodes
    Enterprise  Redis Enterprise: modules, active geo-replication
3
Production starts at Standard; persistence, clustering or zone redundancy means Premium.
4
Most production incidents are on the client. Microsoft's own troubleshooting guidance for timeouts keeps returning to the same causes:
5
    a connection per request   exhausts connections. Create ONE
                               ConnectionMultiplexer and share it.
    thread-pool starvation     .NET adds threads slowly under a
                               burst; raise the minimum worker threads
    large values               one 5 MB value blocks every command
                               queued behind it
    slow commands              KEYS or a huge SMEMBERS stalls the
                               single Redis thread for everyone
6
Memory needs headroom. The maxmemory-reserved and maxfragmentationmemory-reserved settings hold memory back for replication, failover and fragmentation. Leave them at zero and a cache that looks merely full can stall or reject writes exactly when a failover needs memory.
maxmemory-reservedmaxfragmentationmemory-reserved
7
Patching is a failover you did not schedule. Standard and Premium caches are updated by failing over to the replica, so clients see brief disconnects. Set an update schedule so it happens off-peak, and make sure clients reconnect and retry.
8
Prefer Microsoft Entra ID to access keys. An access key is a shared secret copied into every app's configuration. With Entra ID authentication each app connects as its managed identity, and access-key authentication can then be switched off.
9
Clustering changes the programming model. Premium spreads data across shards by hash slot, so multi-key commands and transactions must stay within one slot — key tags such as {order:42}:lines keep related keys together.
{order:42}:lines
10
Across regions, Premium geo-replication links a primary cache to a read-only secondary in another region, to fail over to if the primary region is lost. Enterprise and Azure Managed Redis offer active geo-replication instead, with writes accepted in every region.
11
What the interviewer is probing.1. "Calls to the cache time out under load, but the cache's CPU is low. Where do you look?" Probing: client-side causes. Stalls: "Scale the cache up." Moves up: the client — a new connection per request instead of one shared ConnectionMultiplexer, .NET thread-pool starvation during bursts, or large values and slow commands blocking the single Redis thread.
12
2. "Which tier for production, and why not Basic?" Probing: the replica and the SLA. Stalls: "Basic, and scale later." Moves up: Standard at minimum — Basic is a single node with no replica and no SLA, so any restart or patch empties it; Premium when persistence, clustering or zone redundancy is needed.
13
3. "How would you get the cache's access key out of app settings?" Probing: identity. Stalls: "Move it to Key Vault." Moves up: Key Vault is an improvement, but Entra ID authentication with the app's managed identity removes the secret altogether, after which access-key authentication can be disabled.
14
4. "Would you start a new project on Azure Cache for Redis today?" Probing: whether you are current. Stalls: "Yes, it is the managed Redis." Moves up: it works, but Microsoft has announced its retirement in favour of Azure Managed Redis, so a new design should evaluate that first, and existing caches need a migration plan.