Before settings and diagrams, we need a clear picture of the technology and the problem it solves.

The short definition

Redis is an open-source software that stores data in the main memory of a computer, which is the same fast memory your programs use while they run. Because memory is thousands of times faster than a disk, Redis can answer requests in well under a millisecond. It stores data as keys and values, where a key is a unique name and a value is the information behind that name. Azure Cache for Redis is a managed service that runs Redis for you on Azure. Microsoft creates the machines, installs the software, keeps copies for safety, applies updates, and offers tools to watch and scale it.

People use it for many jobs, but the most common one is caching: keeping a copy of data that is expensive to fetch so that the next request can be served instantly. It is also widely used as a session store, a counter, a leaderboard, a queue, and a lightweight message channel.

Why a cache is needed at all

Databases are built to be correct and durable, not to be the fastest possible. Every question may involve reading from disk, checking permissions, joining tables, and waiting in line behind other users. When many users ask the same thing, a database does the same work again and again. A cache removes that repeated work. The result is faster pages, lower cost on the database, and a system that stays calm when traffic suddenly jumps.

An important note about the product line

Microsoft now offers a newer service called Azure Managed Redis, built on the Redis Enterprise software, and has announced a retirement timeline for Azure Cache for Redis. According to the official retirement notice, the Basic, Standard, and Premium tiers are scheduled to retire on 30 September 2028, with existing instances disabled from 1 October 2028. The Enterprise and Enterprise Flash tiers are scheduled to retire earlier, on 31 March 2027, with existing instances disabled from 1 April 2027. Microsoft recommends moving to Azure Managed Redis well before those dates.

A few words appear again and again. Learn them once and the rest of the guide will read smoothly.

More words you will meet

Two more ideas deserve a plain explanation. The first is the control plane versus the data plane. The control plane is where you create a cache, change its size, or change its settings, usually through the Azure portal or automation. The data plane is where your application reads and writes keys. A long scaling operation on the control plane does not mean individual reads are slow; they are separate worlds that touch only at the edges.

The second is the difference between a cache and a database. A cache holds copies, and losing a cache entry is acceptable because the original still exists elsewhere. A database holds the truth, and losing data is a disaster. Redis can be configured to act more like a database by saving data to disk, but most designs treat it as a copy that can always be rebuilt.

Now we look at the building blocks of a managed cache and how a request travels through them.

The big picture

A managed cache is not a single program on a single machine. In the standard and premium offerings it is a primary node and a replica node, each running the Redis software on its own virtual machine, placed apart so that one hardware failure does not take out both. Around them sit a management service that creates and repairs the machines, a monitoring pipeline that collects numbers, and a network layer that decides who is allowed to connect. In clustered setups several such pairs exist, one for each shard.

flowchart TD
    A[Application] --> B[Endpoint name and port]
    B --> C[Primary node]
    C -- asynchronous copy --> D[Replica node]
    E[Management service] -.-> C
    E -.-> D
    F[Monitoring and metrics] -.-> C
    G[Optional persistence storage] -.-> C
        

The endpoint

Your application never needs to know which machine is the primary. It connects to a host name and a port, and the platform makes sure that name always leads to the node currently serving requests. After a failover the name leads to the new primary, and well-written clients simply reconnect.

The primary and replica nodes

The primary accepts reads and writes. The replica receives a continuous stream of changes from the primary and keeps its own copy in memory. If the primary fails, the replica is promoted. Because the copying is asynchronous, the replica can be a tiny moment behind, so a few very recent writes may be lost in an unlucky failover. This is a trade-off that Redis makes in return for speed.

Shards in a clustered cache

A single machine has limits in memory and in processing power. Clustering solves this by splitting the data across several shards. Every key is mapped to one of many fixed slots, and each shard owns a share of the slots. A client that understands clustering looks at the key, works out the slot, and talks straight to the right shard. This allows the cache to grow beyond one machine and to handle far more traffic.

The management layer

Behind the scenes a management service performs the jobs you would otherwise do by hand: building machines, applying updates, replacing failed nodes, and carrying out your scale requests. You never log in to it. You feel its work when you press scale in the portal and wait, or when a maintenance event briefly restarts a node.

The tier you choose decides features, resilience, and price. Today that choice has two layers: the classic tiers you may already run, and the newer service you are likely to move to.

The classic tiers

Azure Cache for Redis has offered several tiers, each aimed at a different level of need. They share the same basic idea, but they differ in how many copies exist, which features are available, and what promises Microsoft makes about availability.

Azure Managed Redis in plain words

Azure Managed Redis is the newer service, built on Redis Enterprise software and running on current Redis versions. It is meant to replace both the open-source-based tiers and the Enterprise tiers. Instead of choosing between Basic, Standard, and Premium, you choose a family of instance types based on how much memory you need compared with processing power.

flowchart LR
    A[Basic Standard Premium] --> M[Azure Managed Redis]
    B[Enterprise and Enterprise Flash] --> M
    M --> M1[Memory Optimized]
    M --> M2[Balanced]
    M --> M3[Compute Optimized]
    M --> M4[Flash Optimized]
        

Azure Managed Redis also brings a richer feature set. It supports Redis modules such as JSON, search including vector search, probabilistic structures, and time series on the in-memory families. It supports active geo-replication across regions on the in-memory families, high availability across availability zones where regions allow it, data persistence, import and export, scaling, private networking, and sign-in through Microsoft Entra ID. Some of these features are not available on the Flash Optimized family, so check the matrix before choosing it.

Sizing a cache

Sizing starts with a few honest questions. How much data will you keep, and how big is each item on average? How many requests per second do you expect at the busiest moment? How long can items live? What fraction of your data is actually hot? Add headroom, because Redis needs spare memory for internal bookkeeping, for copying during persistence, and for sudden growth. A cache sized exactly to today’s data will struggle tomorrow.

A cache is only as good as the pattern used to fill and refresh it. These are the proven approaches and when each one fits.

Cache-aside

This is the most common pattern. The application first asks the cache. If the data is there, it is used at once. If not, the application reads from the database, saves a copy in the cache with a time to live, and returns the answer. The application is in charge, which makes the pattern simple and tolerant of cache failures: if the cache is down, the application can still read from the database, only more slowly.

sequenceDiagram
    participant App as Application
    participant Cache as Redis cache
    participant DB as Database
    App->>Cache: Ask for item
    alt Found in cache
        Cache-->>App: Return item quickly
    else Not found
        Cache-->>App: Miss
        App->>DB: Read item
        DB-->>App: Item
        App->>Cache: Store item with time to live
        App-->>App: Return item
    end
        

The other patterns

Deciding how long data lives

The time to live is a promise about staleness. A short value keeps data fresh but causes more misses. A long value saves work but risks showing old information. Choose it from the business meaning of the data: a product description can live for hours, a stock level for seconds, a user profile for minutes, and a security decision for as little as it takes to stay safe. When data changes in the database, you can also delete or update the cache entry directly, which keeps freshness high without very short lifetimes.

Three famous problems

Invalidation: keeping the cache honest

There is a famous saying among engineers that the two hardest problems in computing are naming things and knowing when to throw away cached copies. Invalidation is the act of removing or updating a cached item because the original has changed. There are three common approaches. The first is to rely only on time to live, accepting that data may be slightly old until it expires. The second is to delete the cached entry whenever the application changes the source, so the next read loads a fresh copy. The third is to update the cached entry at the same moment as the source, which keeps reads fast but requires care to avoid race conditions where two writers finish in a different order than they started.

Deleting is usually safer than updating, because it avoids writing a value that may already be out of date by the time it lands. When several applications share one cache, agree on who is allowed to change each kind of item. Confusion about ownership is one of the quiet reasons caches show wrong data.

Serialisation and the shape of cached values

Values travel across the network as bytes, so the application must convert its objects into a storable form and back again. The format you choose affects size, speed, and compatibility. Compact binary formats save memory and bandwidth, while readable text formats are easier to inspect when something goes wrong. Whatever you choose, include a version marker so that when the shape of the data changes, old cached items can be recognised and ignored instead of crashing a newer application. A rolling deployment, where old and new versions of the application run side by side for a while, makes this habit especially valuable.

Here we open the hood and see why Redis is so fast, and what that speed costs.

Why memory makes it fast

A disk has to move a physical part or read through a controller, while memory can be reached in a few tens of nanoseconds. Redis keeps all its working data in memory and uses compact structures designed for quick lookup. A key is turned into a number by a hashing step, and that number leads almost directly to the place where the value sits. There is no long search through a table and no waiting for a disk to spin.

The single main thread

The open-source Redis software executes commands one after another on a single main thread. This sounds like a weakness, but it is a clever choice. With only one command running at a time, there is no need for locks, no risk of two commands changing the same value at once, and no time wasted switching between tasks. Each command is so small that millions can pass through in a second. Newer versions use extra threads for reading and writing network data, but the commands themselves still queue up in order.

The trade-off is that a slow command makes everyone behind it wait. A command that scans a huge collection, or fetches a gigantic value, blocks the line. This is why you will hear experts warn against expensive commands and oversized keys. The Redis Enterprise software behind Azure Managed Redis runs several Redis processes on each machine so that more of the available processors are put to use, but the same lesson applies to each shard: keep commands small and quick.

Memory, expiry, and eviction

Memory is limited, so Redis needs rules for what happens when it fills up. There are two separate ideas. Expiry removes keys whose time to live has run out. Redis checks keys when they are touched and also samples keys in the background to find expired ones, so a key may linger briefly after its time is up. Eviction removes keys that are still valid when memory is full, following the chosen policy.

Memory overhead and fragmentation

The memory shown as used is more than the raw size of your data. Every key carries bookkeeping, and the memory manager can leave small unusable gaps over time, a problem called fragmentation. Classic tiers let you reserve a slice of memory to absorb this overhead and the copying work done during saves. Ignoring this reserve is a common cause of sudden out-of-memory trouble in caches that looked half empty.

Persistence: snapshots and logs

Redis can save its data to disk in two ways. A snapshot writes the whole dataset to a file at intervals, which is compact and fast to reload but can lose changes made since the last snapshot. An append-only log records every write command as it happens, which loses very little but takes more space and effort. To take a snapshot safely, Redis makes a lightweight copy of its memory image, and changes made during the save need extra memory, so a busy, nearly full cache can run into trouble while saving.

Replication

A replica starts by copying the whole dataset from the primary, then receives a continuous stream of every change. This copying is asynchronous: the primary does not wait for the replica before answering the client. That keeps writes fast but means that a failover can lose the last few changes. For a cache that is usually acceptable, because the lost entries can be rebuilt.

Clustering and hash slots

In a cluster, the key space is divided into sixteen thousand three hundred and eighty-four slots. A formula turns each key into a slot number, and each shard owns a range of slots. Commands that touch several keys work only when all the keys live in the same slot. To keep related keys together, designers can mark part of the key name so that only that part is used to choose the slot. Forgetting this rule is the most common reason that code works on a single node and fails when moved to a cluster.

flowchart LR
    K[Key name] --> H[Hash function]
    H --> S[Slot number]
    S --> A[Shard 1 owns slots low range]
    S --> B[Shard 2 owns slots middle range]
    S --> C[Shard 3 owns slots high range]
        

Big keys and hot keys

Two kinds of unusual keys cause most performance trouble. A big key is one whose value is very large, such as a list with millions of items. Reading, deleting, or copying it takes so long that it blocks the command line. Even deleting a big key can cause a pause, which surprises many teams. The remedy is to split big collections into smaller ones, trim them regularly, and watch for growth that nobody planned.

A hot key is one that receives a huge share of all requests, such as the front-page banner on a news site. In a cluster, all requests for that key land on one shard, so that shard works hard while others sit idle. Remedies include keeping a copy of the hottest items in the application’s own memory for a few seconds, or storing several copies under slightly different names and picking one at random for each read.

Transactions, scripts, and messages

Redis offers a few features that go beyond simple reads and writes. A transaction groups commands so that they run together without other commands slipping in between, though it does not undo earlier steps if a later one fails. A server-side script lets you send a small program that runs entirely inside Redis, which makes a multi-step action atomic and saves round trips. Both features need all their keys to live in the same slot when used in a cluster. Publish and subscribe lets one part of a system broadcast a message to anyone listening, but, as we saw earlier, it keeps no history.

Let us follow a single request from the application to the cache and back, and then follow the life of the cache itself.

The journey of one request

Suppose a user opens a product page. The application builds a key name for that product and sends a read command. The client library reuses an existing connection, because opening a new connection for every request is slow and wasteful. The command travels over an encrypted channel to the endpoint, reaches the primary node, and joins the queue of commands. When its turn comes, Redis looks up the key in memory and returns the value. The application decodes the value and builds the page. If the key was missing, the application takes the longer path through the database and stores the result for next time.

sequenceDiagram
    participant App as Application
    participant Lib as Client library
    participant EP as Endpoint
    participant Pri as Primary node
    participant Rep as Replica node
    App->>Lib: Ask for key
    Lib->>EP: Send command over encrypted connection
    EP->>Pri: Route to current primary
    Pri->>Pri: Look up key in memory
    Pri-->>Lib: Return value
    Lib-->>App: Decoded result
    Pri->>Rep: Stream any changes made
        

Reads, writes, and connections

A read is the lightest operation. A write changes memory, may update an expiry, and is added to the stream sent to the replica and, where configured, to the persistence log. Connections deserve special care. Each connection uses memory and counts toward a limit, so applications should share a small number of long-lived connections rather than opening many short ones. Many Redis clients can send several commands over one connection at the same time, which keeps latency low.

Batching and pipelining

Every round trip across the network costs time, even if Redis answers instantly. When an application needs many small results, it can send a batch of commands together and read all replies at once. This technique, called pipelining, can raise throughput dramatically. The balance is to keep batches modest so that one huge batch does not hold up the queue for other users.

The life of the cache itself

What a good client library does for you

The library between your application and the cache does a great deal of invisible work, and knowing it helps you configure it well. It keeps connections open and multiplexes many requests over each one. It notices when a connection breaks and tries to rebuild it. In a cluster it learns which shard owns which slot, follows redirections when slots move, and refreshes its map after a failover. It converts values between your objects and bytes. Every one of these behaviours has settings, and the defaults are not always right for your workload.

Redis is more than a place to store text. It offers ready-made structures that solve real problems with a single command.

Use cases in plain language

Choosing key names

Good key names are short, readable, and consistent. A common habit is to build them from parts, such as the kind of object, its identity, and the field, separated by a colon. Consistent names make monitoring easier, let teams avoid collisions, and allow cleaning up related keys together. Very long names waste memory when you have millions of keys, so aim for clear but compact.

Matching structure to problem

The skill of using Redis well is largely the skill of choosing the right structure. A common beginner habit is to turn everything into one large text value and store it under a single key. This works, but it forces the application to read and rewrite the entire value for the smallest change. A hash lets you change one field. A sorted set lets you add one score. A list lets you push one item. Each of these changes is tiny and atomic, so the cache does less work, uses less network, and avoids the race conditions that appear when two users rewrite the same big value at once.

Because a cache often holds sessions, tokens, and customer data, it deserves the same care as a database. Security works best in layers.

Layer 1: network isolation

The first question is who can even reach the cache. A cache can have a public endpoint protected by firewall rules that list allowed addresses, or it can be reached only through private paths. A private endpoint gives the cache a private address inside your own virtual network, so traffic never crosses the open internet. In the premium classic tier, the cache can also be placed directly into your virtual network. The safest default is to turn off public access and allow only private paths.

Layer 2: encrypted connections

Data travelling between application and cache should always be encrypted. Classic caches accept encrypted connections on one port and, if you ask, plain connections on another. The plain port is off by default and should stay off. Set a minimum protocol version so that outdated and weak versions are refused, and make sure your clients actually verify the server’s certificate.

Layer 3: authentication

Authentication answers “who are you?”. There are two main ways. The first is an access key, a long secret shared by everyone who uses it. It is simple, but anyone who holds it has full power, and it must be rotated carefully. The second is Microsoft Entra authentication, which lets applications and people sign in with their identity. Applications running in Azure can use a managed identity, so no secret is stored at all. Entra sign-in also allows access to be granted per person or per service and removed at once from one central place.

Layer 4: least privilege and data protection

Give each application only the access it needs. A service that only reads sessions should not be able to erase the whole cache. Keep access keys, if you must use them, in a secure vault rather than in configuration files, and rotate them on a schedule using the primary and secondary keys so that rotation causes no outage. Do not store highly sensitive data in the cache unless you have to, and when you do, keep lifetimes short and consider encrypting the value inside the application before storing it.

Layer 5: logging and review

Turn on diagnostic logging and send it to a place your security team watches. Review who has access regularly, remove old identities, and set alerts on unusual patterns such as a burst of failed sign-ins or a sudden jump in connections.

Roles, ownership, and review

Security is not only technology; it is also habit. Decide who owns each cache, who may change its settings, and who may read or write data. Management actions, such as changing the network rules or regenerating keys, should be limited to a small group, while applications receive only data access. Review these assignments on a schedule and remove anyone who has changed teams. When a person leaves, their access should end the same day.

What should never go into a cache

Because a cache is easy to use, it is tempting to put anything there. Be selective. Highly sensitive items such as full payment details, government identity numbers, and passwords should not be cached at all unless there is a strong reason and strong protections. When personal data must be cached, keep lifetimes short, store only the fields needed, and make sure your privacy rules cover the cache as much as the database. Remember that a cache is also a copy, and copies must be deleted when people ask for their data to be removed.

Things break. A good design says exactly what happens when a node, a building, or a whole region disappears.

Two ideas to keep apart

High availability means surviving small failures, such as one machine dying, with a short pause. Disaster recovery means surviving large failures, such as a region being unavailable, usually with a longer pause and a plan. Because a cache holds copies, the honest first question is whether you need to protect the cache contents at all. Often the best disaster recovery for a cache is a clean, empty cache in another place that warms up from the database.

Availability inside one region

Persistence in practice

Persistence lets a cache reload its data after a restart or a serious failure, instead of starting empty. It is useful when rebuilding the cache is very expensive or when the cache is used for data that is hard to recreate. It has a cost: extra disk writes, extra memory during snapshots, and some added delay. Decide using your recovery needs, not habit. Many pure caches run without any persistence and are happier for it.

Geo-replication

Geo-replication copies data between regions. In the classic premium tier, a primary cache in one region is linked to a secondary in another, and the secondary is read-only until you fail over. In the newer service and in the older enterprise tiers, active geo-replication lets several caches in different regions all accept writes and merge their changes, which allows users in different parts of the world to read and write locally. This is powerful, but it changes how you think about conflicts, because two regions might change the same item at nearly the same time.

flowchart LR
    U1[Users in Region A] --> C1[Cache in Region A]
    U2[Users in Region B] --> C2[Cache in Region B]
    C1  C2
    C1 -.-> D1[Local database A]
    C2 -.-> D2[Local database B]
        

Making applications failover-friendly

The platform can only do half the work. Applications must reconnect automatically, retry after a short delay that grows with each attempt, and set sensible time limits so that a failing cache does not freeze the whole system. They should also be able to run without the cache, even slowly, by falling back to the database, and they should limit how hard they hit the database during that fallback.

Warming an empty cache safely

A new, restarted, or failed-over cache may be empty. If your traffic is heavy, an empty cache sends every request to the database at once, which can overwhelm it. A warm-up plan solves this. Before switching traffic, load the most popular items using a list taken from recent usage. Then let traffic return in steps rather than all at once. Combine this with limits on how many database queries can run at the same time, so that even in the worst moment the database stays alive.

How your application reaches the cache decides its speed, its safety, and how easy it is to fix when something goes wrong.

Distance is latency

Even at the speed of light, a signal needs time to travel. A cache that answers in a fraction of a millisecond is wasted if the application sits in another region and each request must cross hundreds of kilometres. Place the cache in the same region as the application, and where possible in the same availability zone or close to it. This one decision often matters more than any tuning of the cache itself.

Ways to reach a cache

flowchart TD
    APP[Application subnet] --> PE[Private endpoint]
    OFF[On-premises network] -->|VPN or private circuit| HUB[Hub virtual network]
    HUB --> PE
    PE --> R[Redis cache]
    DNS[Private name zone] -.-> PE
    NSG[Network rules] -.-> PE
        

Names and ports

Applications connect by host name. With a private endpoint, the name must resolve to the private address from every network that needs access. This is the most common source of mysterious failures: a name that resolves correctly from one network and to the wrong place from another. Test name resolution from every client network before going live. Ports also matter. Classic caches use one port for encrypted traffic and another for plain traffic, and the plain one should stay off. The newer service uses a different port from the classic tiers, so firewall rules and connection settings must be updated when you migrate.

Connection hygiene

Connections are a limited resource. Each client holds memory on the server, and every tier has a ceiling on how many connections it accepts. Web applications that create a new connection for every request can exhaust that ceiling within seconds under load. Create one shared client when the application starts, reuse it for the life of the process, and let the library repair broken connections on its own. Set connection and command time limits so that a stuck call fails fast instead of piling up.

Firewalls, on-premises users, and developers

Developers often want to connect to a cache from their own computers to look at keys or test ideas. Handing out public access for this is risky. Safer options include a shared jump machine inside the private network, a secure tunnel through the organisation’s VPN, or a dedicated non-production cache with relaxed rules. Whatever you choose, make it easy and documented, because people who find the safe path difficult will invent an unsafe one.

For users and servers in on-premises data centres, the private link into Azure must carry both the traffic and the name lookups. A common failure is that the link works but the office name servers do not know how to resolve the cache’s private name. Set up forwarding for the private zone and test from a real office computer before announcing that the cache is ready.

The announced retirement dates turn migration from an option into a plan. Here is how to approach it calmly.

Know your dates and your tier

The first step is an inventory. List every cache in every subscription, its tier, its size, its owner, and the applications that use it. Then match each cache to its deadline. Enterprise and Enterprise Flash caches come first, because their retirement is scheduled for 31 March 2027. Basic, Standard, and Premium caches follow, with retirement scheduled for 30 September 2028. Microsoft recommends not waiting for the deadline, because early moves leave time to test and to fix surprises.

flowchart TD
    A[Inventory all caches] --> B[Match each cache to its retirement date]
    B --> C[Review features used]
    C --> D[Choose target family and size]
    D --> E[Check client library and commands for cluster support]
    E --> F[Create new cache and test]
    F --> G[Move data or let cache warm]
    G --> H[Switch application to new endpoint]
    H --> I[Watch metrics then remove old cache]
        

What changes for your application

Moving the data, or not

The cleverest question in migration is whether you need to move the data at all. If your cache holds only copies of data from a database, you can often create the new cache, point the application at it, and let it fill naturally. Early traffic will miss more often, so plan the switch for a quiet period and protect the database from the extra load. If the cache holds data that is hard to rebuild, use the methods described in the official migration guides, which cover options for copying existing data and keeping continuity. Whichever route you take, rehearse it first on a copy of the real workload.

Testing a migration properly

A migration test is more than checking that the application starts. Run the same load you expect in production against the new cache and compare hit rate, latency, memory use, and error counts with the old one. Include the unpleasant cases: a failover test, a burst of traffic after an empty start, and a client reconnecting after a network blip. Verify that every command your code uses behaves correctly across slots. Ask each application team to sign off with a short written note, so that there is a clear record of what was tested and by whom.

A cache that nobody watches fails in silence. Good monitoring turns “the site feels slow” into a clear, fixable fact.

The numbers that matter

Hit rate is the heartbeat

The ratio of hits to total requests is the simplest sign of a healthy cache. A high hit rate means most users are served from memory. A falling hit rate may mean that lifetimes are too short, that the cache is too small and keeps evicting useful data, or that a new feature is asking for data that was never cached. Watch it over days as well as minutes, because slow drifts reveal design problems.

Logs, alerts, and dashboards

Send platform metrics and diagnostic logs to a central workspace so that you can chart them, search them, and keep history for longer. Create alerts for memory above a sensible level, server load that stays high, a rising count of evictions, a sudden fall in hit rate, and any burst of connection errors. Give each alert an owner and a short written response guide. An alert that nobody understands will soon be ignored.

Finding the slow culprit

When load is high, the question is which commands are responsible. Redis can show a record of slow commands and can report the biggest keys in memory. Large values, huge collections, and commands that scan everything are the usual suspects. Fixing a handful of them often removes most of the pain without adding any hardware.

Troubleshooting four common symptoms

A rhythm for capacity planning

Capacity planning is not a single event before launch; it is a habit. Each month, look at the peak values of memory, server load, connections, and bandwidth, and compare them with the limits of your tier. Look at how they have grown over the last quarter and project a few months ahead. If the peak of any measure regularly crosses a comfortable level, such as more than about two thirds of its limit, plan to scale before the next busy season. Scaling in a hurry, during an incident, is far more stressful and more risky than scaling calmly on a quiet day.

A pattern is a proven solution. An anti-pattern is a tempting shortcut that usually causes pain later.

Patterns worth adopting

flowchart LR
    REQ[Request] --> L1[Local memory cache]
    L1 -->|miss| L2[Shared Redis cache]
    L2 -->|miss| DB[Database]
    DB --> L2
    L2 --> L1
        

Anti-patterns to avoid

Reading a design with a critical eye

When reviewing a cache design, a short list of questions often reveals the weak spots faster than reading every detail. What happens if the cache is empty right now? What happens if it answers slowly for ten minutes? What is the largest value stored, and the most popular key? Which data would be harmful if lost, and where is its durable home? Who can read the cache, and how would we know if someone should not? If the team can answer these calmly and concretely, the design is probably in good shape. If the answers are vague, the design needs more work before it meets real users.

This chapter gathers the habits that separate calm operations from constant firefighting.

Best practices by area

Common mistakes and how to avoid them

A launch checklist

Teaching the team

Tools do not keep a cache healthy; people do. Hold a short session for every new developer explaining what the cache is for, which patterns the team uses, and which commands are forbidden in production. Keep a one-page guide of key naming rules and lifetimes. Share what you learn from incidents in short, blame-free notes. Over time, these small habits do more for reliability than any single feature of the platform.

Every good design is a balance. Here we weigh what a managed cache gives you against what it asks in return, and how to keep the bill sensible.

How the bill is made

The cost of a cache is mainly the size and type of the nodes you choose, charged for every hour they exist, whether busy or idle. More memory, more shards, more compute, and extra replicas all raise the price. Features such as geo-replication add the cost of extra caches in other regions. Data that leaves a region adds network charges. Because prices change and vary by region, always confirm numbers using the official pricing page and calculator, and avoid quoting stale figures in a business case.

Ways to spend less without hurting users

A worked cost-thinking example

Imagine a company with three systems that use caches: a busy shopping site, an internal reporting tool, and a development environment. A careless design gives each one the same large, replicated, geo-replicated cache. A thoughtful design asks what each one really needs. The shopping site has strict speed needs and global users, so it earns a larger cache with replicas and perhaps geo-replication. The reporting tool is used only in office hours and its results can be rebuilt, so a modest cache with no persistence is enough. The development environment needs the same features as production to test properly, but at the smallest size that still behaves correctly.

The saving does not come from clever tricks. It comes from asking, for each system, what is truly required and refusing to pay for more. Repeating the exercise every quarter keeps the bill honest as workloads grow, shrink, or retire. It also gives a natural moment to plan the move to the newer service, because choosing a family there is just the same exercise with different names.

Here are four everyday situations that show how the ideas in this guide fit together. The names are illustrative, not real customers.

flowchart TD
    U[Shoppers] --> W[Web tier]
    W --> R[Managed Redis cache]
    R -->|miss| API[Product service]
    API --> DB[Database]
    API --> R
    W --> S[Session data in cache]
        

When another service may be a better fit

A cache is not the answer to everything. If you need rich queries across many fields, relationships between records, or strong guarantees that data is never lost, a database is the right home. If you must deliver business events reliably to many consumers, a dedicated messaging service is safer than simple publish and subscribe. If your dataset is huge and rarely re-read, caching it all wastes money. Choosing the right tool for each job is a core part of good architecture.

Short answers to the questions teams ask most often.

Microsoft has announced a retirement timeline. Basic, Standard, and Premium are scheduled to retire on 30 September 2028, and Enterprise and Enterprise Flash on 31 March 2027. Microsoft recommends moving to Azure Managed Redis. Always confirm the dates on the official retirement page.

A cache keeps fast copies of data that can be rebuilt, and a database keeps the durable truth. Redis can persist data to disk, but most designs still treat it as a copy.

It keeps data in memory, uses compact structures, and runs commands one after another without locks, so each small command finishes in a tiny fraction of a millisecond.

Yes. Keys can expire or be evicted, and asynchronous copying means a failover can lose the very latest writes. Design so that lost data can be rebuilt from the source.

The replica becomes the primary, the endpoint name leads to it, and connections drop briefly. Applications with automatic reconnection and retry usually recover in seconds.

For a pure cache where everything can be rebuilt, evicting least recently used keys is a sensible choice. If you store keys without lifetimes alongside cached ones, think carefully so important keys are not removed or writes do not fail.

You need it when one machine cannot hold your data or handle your traffic. The newer service is clustered by default, with a non-clustered option for smaller caches, so plan for cluster rules in your code.

Prefer Microsoft Entra authentication with managed identities, so no shared secret exists. If you must use access keys, keep them in a vault and rotate them using the primary and secondary keys in turn.

Usually not. A private endpoint with encrypted connections is the safer default, and the plain unencrypted port should stay off.

At least the host name and credentials, plus a review of client library cluster support, multi-key commands, ports, and network rules. Choose the family that fits your memory and compute needs and test thoroughly before switching.

It depends on the workload, but the trend matters most. A steady high rate means the cache is working. A falling rate signals problems with lifetimes, sizing, or what is being cached.

Test connectivity and name resolution from every client network, behaviour under realistic load, a reboot or failover, the fallback to the database when the cache is empty, and your alerts.

Azure Cache for Redis brings the speed of in-memory data to your applications while Microsoft handles the machines, updates, and repair. It works best when you treat it as a fast copy of data that lives safely elsewhere, fill it with proven patterns such as cache-aside, give every key a sensible lifetime, keep commands and values small, and let applications reconnect and retry. It must be secured in layers, watched through a few key metrics, and protected with the level of resilience your business really needs. Finally, because Microsoft has announced retirement dates for the classic service and recommends Azure Managed Redis, every team should plan its migration now, starting with the earliest deadline.