Start with the one-sentence idea, then build up the picture slowly.

Azure Cache for Redis is a managed service from Microsoft that gives you a Redis server running in Azure. Redis is a popular open-source program that stores data in a computer’s main memory and hands it back extremely quickly. The word managed means Microsoft installs the software, keeps it updated, replaces failed machines, and offers settings for size and safety, while you simply connect your application and use it.

To understand why this matters, we need a few simple words. Memory, often called RAM, is the very fast short-term storage a computer uses while it works. Disk is the slower long-term storage where files and databases usually live. Memory can be hundreds or thousands of times faster than a disk, but it is more expensive per gigabyte and it forgets its contents when power is lost. Redis exploits this: it keeps data in memory so answers come back almost instantly.

A cache is a place where copies of frequently needed data are kept close to the program that wants them, so that the program does not have to fetch the data from a slower source every time. The original data stays safely in its main home, usually a database. The cache holds a convenient, quickly reachable copy. If the copy is ever lost, nothing precious is gone, because the original still exists and the cache simply fills up again.

Redis is more than a simple cache, though. Its name comes from “remote dictionary server”, and at heart it is a key-value store: you give it a name, called a key, and a piece of data, called a value, and later you ask for the value by its key. Unlike simpler stores, its values can be rich shapes such as lists, sets, and ranked collections, and it offers operations that work on those shapes directly. This makes it useful for many jobs beyond caching, such as session storage, leaderboards, counters, and messaging.

To see why a cache is valuable, look at where the time goes.

A typical web application has three parts. The user’s browser or phone asks for a page. An application server receives the request and decides what to do. A database stores the real data, such as products, customers, and orders. For every page, the application usually asks the database one or more questions, waits for the answers, builds the page, and sends it back.

The database becomes the bottleneck

A bottleneck is the narrowest part of a system, which limits how much can flow through. In most applications the database is the bottleneck. It reads from disk, checks permissions, combines information from several tables, and handles many users at once. When traffic grows, the database gets busier and slower, and every user feels it. Buying a bigger database helps for a while, but it is costly, and it does not fix the real waste, which is answering the same question again and again.

Repeated questions are everywhere

Study almost any application and you find the same questions repeated. A product page is viewed by thousands of people, but the product changes rarely. A list of countries or categories is read all day and edited once a year. A user’s profile is loaded on every click. Computing these answers from scratch each time wastes time and money, and a cache lets you compute once and reuse many times.

Delay also comes from distance and from calculation

Besides disk speed, time is lost in two other ways. Network distance adds delay when the database is far from the application. And heavy calculation, such as building a complex report or ranking millions of items, can take seconds. Caching the finished result removes both delays for later requests.

Why speed matters to the business

People leave slow pages. Even small delays reduce the number of visitors who finish a purchase or keep reading. Fast responses also lower cost, because the same machines can serve more users. A good cache therefore improves both user happiness and the bill.

Every service exists because somebody had a painful problem. Here are the main ones.

Sudden spikes in traffic

Consider a news site on the day of a big event. Traffic may jump a hundred times in minutes. The same few articles are requested by almost everyone. If every request goes to the database, the database collapses. If the articles sit in a cache, the cache serves them effortlessly and the database sees only a trickle.

Many servers needing one truth

When an application runs on many servers behind a load balancer, each server cannot keep a private notebook of user sessions, because the next click may go to a different server. A shared cache solves this: any server can read and write the same session data quickly.

Smart counting and ranking

Some problems are awkward in a regular database but simple in Redis. Counting how many requests a user made in the last minute, ranking players by score in real time, or checking whether an item was already processed are all natural fits for Redis structures.

Eight building blocks. Learn these and the rest of the topic becomes easy to follow.

Key and value

Everything in Redis is stored under a key, a text name such as “user:1001:profile”. The value is the data kept under that name. Good teams use clear, consistent naming for keys, with colons separating parts, so that anyone can tell what a key holds.

Cache hit and cache miss

A cache hit happens when the application asks for data and the cache has it. A cache miss happens when the cache does not have it, so the application must fetch it from the original source. The share of requests that are hits is called the hit ratio, and it is the single most important health number of a cache. A high hit ratio means the cache is doing its job.

Time to live

A time to live, written TTL, is a countdown attached to a key. When the countdown reaches zero, Redis removes the key automatically. TTLs keep cached data from becoming too old and stop the cache from filling up with forgotten items.

Eviction

Memory is limited. When it fills up, Redis must decide what to do with a new item. Eviction means removing some existing keys to make room, following a rule called an eviction policy. For example, one policy removes the least recently used keys first, and another refuses new writes. We study these in Chapter 6.

Data structures

A data structure is a particular way of organising information. Redis offers several: plain text values, hashes that hold named fields like a small record, lists that keep items in order, sets that keep unique items, sorted sets that keep unique items ranked by a score, and others. Chapter 8 shows how they are used.

Tier and size

In Azure, you choose a tier, which is a package of features and reliability, and a size, which sets the memory and power. Larger sizes cost more. We compare the tiers in Chapter 9.

Clustering and sharding

Sharding means splitting data into pieces, called shards, spread over several machines. Clustering is Redis’s way of doing this automatically. It lets a cache hold more data and handle more requests than one machine could manage.

Replication

Replication means keeping a copy of the data on a second machine, called a replica, so that if the first machine fails, the copy can take over.

How the pieces fit together, from your application to the cache machines.

Look at the diagram below from left to right. Users reach your application servers. The servers first ask the cache for what they need. If the cache has it, the answer returns right away. If not, the servers ask the database, then place a copy into the cache for next time. The cache itself may consist of a primary machine, which handles requests, and a replica, which keeps a copy ready to take over.

flowchart LR
    U["Users"] --> LB["Load balancer"]
    LB --> A1["App server 1"]
    LB --> A2["App server 2"]
    A1 --> C["Azure Cache for Redis"]
    A2 --> C
    C --> P["Primary node"]
    P -.->|"Replication"| R["Replica node"]
    A1 --> DB["Database"]
    A2 --> DB

What Microsoft manages and what you manage

Microsoft manages the virtual machines that run Redis, the operating system, the Redis software, the security patches, the replacement of failed nodes, and the platform’s monitoring hooks. You manage the choice of tier and size, the network and access settings, the way your application uses the cache, the keys and their lifetimes, and the decision about what is safe to keep there. This is the shared responsibility model, and it leans heavily toward Microsoft compared with installing Redis yourself.

The client library

Your application talks to Redis through a client library, a ready-made software kit for your programming language. The library opens connections, sends commands, and reads answers. A good habit is to create one shared connection object per application and reuse it, instead of opening a new connection for every request, because opening connections is slow and the cache can only hold a limited number of them.

Ports and encryption

Clients connect over the network to a named address and a port, which is like a numbered door on a server. Azure Cache for Redis offers an encrypted door, which is the recommended one, and an unencrypted door that is turned off by default. Encrypted connections use TLS, a standard way of scrambling data while it travels, so that nobody on the network can read it.

What happens inside Redis when a request arrives.

When your application sends a command, such as “give me the value for this key”, the request travels over the network to the Redis server. The server reads the command, looks up the key in an internal table that sits in memory, and returns the value. Because everything happens in memory, and because the lookup structure is very efficient, a simple operation usually finishes in a tiny fraction of a millisecond. The network trip often takes longer than the lookup itself.

A mostly single-lane road

A key part of Redis’s design is that it executes commands one after another, in a single main line of work. This might sound slow, but it removes the need for locks and juggling, and it makes each command atomic, meaning it either happens completely or not at all, with no other command interrupting it halfway. Newer versions use extra threads for reading and writing network data, but the principle of orderly command execution remains. The consequence for you is important: a single slow command blocks everyone behind it.

Commands to treat with care

Some commands touch every item in a large collection, or every key in the cache. They are cheap on small data and disastrous on large data. The command that lists all keys at once, for example, should not be used on a busy production cache, because it holds the single lane while it works. Redis provides gentler alternatives that step through keys in small batches. Good practice is to prefer commands whose cost does not grow with the size of the data.

Expiry

Redis removes keys whose TTL has run out in two ways. When a client asks for an expired key, Redis notices and deletes it. In the background, it also samples keys now and then and removes expired ones, so that forgotten keys do not pile up. Because of this, expiry is accurate for reads but the memory of an expired key may be freed slightly later.

Eviction policies

When memory reaches its limit, the eviction policy decides what happens. Common choices include removing the least recently used keys among all keys, removing the least recently used keys only among those with a TTL, removing the keys closest to expiring, picking randomly, or refusing new writes with an error. The right policy depends on the job. A pure cache usually evicts the least recently used items. A store that must never drop data should refuse writes instead, and should be sized with care. Check which policy your cache uses by default and change it deliberately.

flowchart TD
    W["New write arrives"] --> M{"Is memory full?"}
    M -->|"No"| S["Store the key"]
    M -->|"Yes"| E{"Eviction policy"}
    E -->|"Evict least recently used"| X["Remove old keys then store"]
    E -->|"Evict only keys with TTL"| Y["Remove expiring keys then store"]
    E -->|"No eviction"| Z["Reject the write with an error"]

Memory overhead and fragmentation

Redis needs a little extra memory for its own bookkeeping, and for copying data during certain operations. Over time, memory can also become fragmented, meaning small unused gaps are left between items, like gaps in a badly packed suitcase. For these reasons Azure lets you reserve a portion of memory for non-data work, and you should never plan to fill the cache to the brim.

The life of a request, and the life of a cache project.

The cache-aside pattern

The most common way to use a cache is called cache-aside, which means the application itself looks after the cache. For a read, the application first asks the cache. On a hit, it uses the answer. On a miss, it reads from the database, stores a copy in the cache with a TTL, and then continues. For a change, it updates the database and then removes or updates the cached copy, so that readers do not see old information.

flowchart TD
    A["Application needs data"] --> B["Ask the cache"]
    B --> C{"Found in cache?"}
    C -->|"Yes - hit"| D["Return the cached value"]
    C -->|"No - miss"| E["Read from the database"]
    E --> F["Store a copy in the cache with a TTL"]
    F --> G["Return the value"]

Writes and invalidation

Invalidation means removing or refreshing cached data when the original changes. It is famously one of the hardest problems in computing, because the cache must not keep serving old data once the truth has changed. The simplest safe approach is to delete the cached key whenever the underlying data is updated, and let the next read refill it. Pair this with a sensible TTL as a safety net, so that even a missed invalidation corrects itself in time.

Redis is much more than a place to park copies of database rows.

Use case: session storage

A session is the memory a website keeps about a visitor between clicks, such as who is logged in and what is in the basket. Storing sessions in Redis lets any application server find any visitor’s session quickly. A TTL makes idle sessions disappear on their own.

Use case: leaderboards

In an online game, players want to see their rank instantly. A sorted set stores each player with a score, and Redis can add a score, find a player’s rank, and list the top players, all in a fraction of a millisecond. Doing the same in a database means sorting large tables on every request.

Use case: rate limiting

Rate limiting means restricting how many requests a user or program may make in a period, to prevent abuse. A counter with a short TTL does the job: each request adds one, and when the count passes the limit the request is refused. The counter vanishes by itself when the time window ends.

Use case: messaging

Redis offers publish and subscribe, where programs subscribe to a named channel and receive messages that others publish to it. It is useful for quick notifications, such as telling every web server to drop a cached item. Messages are not stored, so a subscriber that is offline misses them. For messages that must not be lost, use a durable messaging service instead.

Use case: distributed locks

When several programs must not do the same job at the same time, such as running a nightly clean-up, they can compete for a lock key in Redis. Whoever creates the key first holds the lock, and a TTL ensures it is released even if the holder crashes. Locks built this way need careful design, so use a well-tested library and treat them as a helper, not as a guarantee for money-critical operations.

Use case: caching whole results

Rendered page fragments, API responses from slow outside services, and the output of heavy calculations are all good candidates. They are costly to produce and often identical for many users.

Choosing the right package is the biggest decision you will make about the service.

Azure Cache for Redis has been offered in several tiers, each balancing features, reliability, and price. The details, names, and availability of tiers change over time, so treat the descriptions below as the general shape and confirm the current options in Microsoft’s documentation, including the newer managed Redis offering.

Sizing the memory

Start by estimating how much data you want to keep in the cache. Multiply the number of items by their average size, then add room for overhead, for the reserved memory, and for growth. Do not fill the cache to the brim, because eviction, fragmentation, and background work all need breathing space. A common approach is to leave a healthy margin of free memory rather than running near the limit.

Sizing the power

Memory is only half the story. The cache also needs enough processing power and network capacity for your request rate. Large values, heavy commands, and many connections all consume extra power. Test with realistic traffic, and watch the server load metric, which shows how busy Redis’s main line of work is.

Scaling up and scaling out

Scaling up means moving to a bigger size or a higher tier, which gives more memory and power on the same layout. Scaling out means adding shards with clustering, so data and traffic spread over several machines. Scaling operations can briefly affect connections, so plan them for quiet periods and make sure your application reconnects gracefully.

What it costs

You pay for the tier and size for every hour the cache exists, whether it is busy or idle, and extra features such as geographic replication add to the cost. Network traffic leaving Azure can be charged. Prices differ by region, so use the Azure pricing calculator with your own numbers. Reserving capacity for one or three years can lower the price of a steady, long-lived cache.

Machines fail and buildings lose power. Good design expects that.

Availability means the cache is reachable when you need it. In tiers that have a primary and a replica, the replica keeps a copy of the data. If the primary fails, or is stopped for patching, the service promotes the replica to take over, usually within seconds. During this switch, connections drop and some requests fail, so the application must retry politely and reconnect.

flowchart TD
    APP["Application"] --> PRI["Primary node - zone 1"]
    PRI -.->|"Copies data"| REP["Replica node - zone 2"]
    PRI -->|"Primary fails"| FAIL["Service detects the failure"]
    FAIL --> PROM["Replica is promoted to primary"]
    PROM --> APP2["Application reconnects and retries"]

Zones

An availability zone is a separate data centre building, or group of buildings, inside a region, with its own power, cooling, and network. Where the tier supports it, placing the primary and replica in different zones means that the loss of one whole building does not stop the cache.

Persistence

By default, a cache lives in memory, so if the whole thing restarts, the data may be gone. Persistence means saving data to disk as well, so that it can be reloaded after a restart. Redis does this by taking regular snapshots of the data, or by writing a log of every change, and some tiers let you turn these on and store them in an Azure storage account. Persistence reduces the pain of a full restart, but it is not a replacement for a database, and it can add some work on the server.

Geographic replication

For disaster recovery across regions, higher tiers support linking caches in two regions. One acts as the main and the other as a secondary copy, with data replicated across. If the main region fails, you switch to the secondary. Some advanced offerings allow writes in more than one region. These features add cost and complexity, so use them only when the business truly needs survival of a whole-region loss.

Patching and planned events

Microsoft regularly updates the Redis software and the machines it runs on. In replicated tiers, updates are done one node at a time so the cache stays up, but connections may still reset. The application’s client library should reconnect automatically, and your code should treat a failed cache call as a cache miss, not as a fatal error. Many teams run drills that kill the cache connection on purpose, to prove their program survives.

Using a cache well is a skill. Here are the main strategies and the traps around them.

Three ways to write

Choosing lifetimes

A TTL is a promise about how old a cached answer may be. Data that changes by the minute needs a short TTL, and data that changes yearly can have a long one. Add a little random variation to TTLs so that many keys do not all expire in the same second, which leads to the next problem.

The cache stampede

A cache stampede happens when a very popular key expires, and suddenly hundreds of requests all miss at the same moment and all rush to the database to rebuild it. The database, which the cache was protecting, is flooded. Defences include adding random variation to TTLs, letting only one request rebuild the value while others wait briefly or use the slightly old value, and refreshing popular keys shortly before they expire.

Cache penetration

Penetration means repeated requests for data that does not exist at all, such as a made-up product number. Each request misses the cache and goes to the database, which also has nothing, so the cache never helps. Defences include caching the “not found” answer for a short time, and checking the format of requests before they reach the cache.

Stale data

Whenever data is copied, the copy can become out of date. Decide for each kind of data how stale it may be. A product description a few minutes old harms no one, but an account balance a few minutes old might. For sensitive values, skip the cache or invalidate it immediately on every change.

Hot keys and big keys

A hot key is one key that receives a huge share of requests, which can overload the single machine that holds it, even in a cluster. A big key is one holding a very large value or collection, which takes long to read, write, or delete, and blocks the single lane of work. Break big values into pieces, and spread hot keys with copies or local short-term caching in the application.

Who may enter, from where, and how data is protected.

Redis was designed to run inside trusted networks, and it does not defend itself well when exposed to the open internet. Security for a managed cache therefore has four questions. Who may connect, which is identity. From where they may connect, which is networking. How the data travels, which is encryption in transit. And how it is stored, which is encryption at rest and the safety of backups.

Identity and access

The traditional way to connect is with an access key, a long secret string given to the application. Anyone holding the key has full access, so it must be guarded like a master key. A better approach, where supported, is signing in with Microsoft Entra ID, Microsoft’s identity service, so that applications and people receive only the permissions they need, and no shared secret has to be stored. For programs running in Azure, a managed identity lets the application sign in without any secret in its settings.

Network protection

By default a cache may be reachable through a public address, protected by its key. For better safety, use a private endpoint, which gives the cache a private address inside your own virtual network, so traffic never crosses the public internet. Firewall rules can also restrict which addresses may connect. For caches that hold anything sensitive, public access should be switched off.

Encryption

Use the encrypted port with a modern version of TLS, and disable the unencrypted port. Data in the cache memory is not readable from outside, but if persistence or exported backups are used, make sure the storage account that holds them is encrypted and locked down.

Security checklist

• Prefer identity-based access to shared keys, and use managed identities for applications.
• Keep keys secret. Store them in a key vault, never in code or shared documents, and rotate them on a schedule.
• Restrict the network using private endpoints and firewall rules, and turn off public access when you can.
• Use only encrypted connections and keep the unencrypted port disabled.
• Limit what is cached. Do not keep passwords, full card numbers, or other highly sensitive data in the cache.
• Protect backups and persistence storage with the same care as the cache.
• Log and alert on unusual access so strange behaviour is noticed.
• Disable dangerous commands where your setup allows it, and keep administrators few.

You cannot manage what you cannot see. Here is what to watch.

Monitoring means continuously checking the health and behaviour of your system. Metrics are numbers measured over time. Logs are written records of events. Azure Monitor collects metrics from the cache, and you can set alerts, which are automatic messages sent when a number crosses a line you choose.

The hit ratio story

If you remember only one number, remember the hit ratio. Imagine a ratio of ninety-five percent: only five of every hundred requests reach the database, a twenty-fold reduction. If the ratio drops to fifty percent, half the traffic returns to the database, and the benefit of the cache has largely gone. A sudden drop usually means something changed, such as a deployment that changed key names, a flood of requests for unusual data, or memory pressure causing evictions.

Find slow work

Redis keeps a record of commands that took longer than a chosen time. Reviewing this slow log shows which commands hold up the single lane of work. Typical culprits are commands over huge collections, scanning all keys, and enormous values.

Watch the application side too

Record in your own application logs how often cache calls fail, time out, or are retried. Slowness often comes from the client, for example from too few connections, or a network path that crosses regions, rather than from the cache itself. Keep the application and the cache in the same region, and as close in the network as you can.

Redis is one of several ways to speed up an application. Compare before you choose.

Features and managed offerings change over time, so confirm current capabilities and limits in the documentation before you design around any of them.

A simple decision guide

flowchart TD
    Q1{"Is the data static web files like images and scripts?"} -->|"Yes"| CDN["Use a content delivery network"]
    Q1 -->|"No"| Q2{"Must it be shared by many servers?"}
    Q2 -->|"No"| MEM["An in-process cache may be enough"]
    Q2 -->|"Yes"| Q3{"Can it be rebuilt if lost?"}
    Q3 -->|"Yes"| RED["Use Azure Cache for Redis"]
    Q3 -->|"No"| DB["Keep it in a durable database and cache a copy in Redis"]

Using several together

Real systems often layer these. A content delivery network serves images, Redis holds sessions and popular query results, a tiny in-process cache absorbs the hottest keys, and a durable database keeps the truth. Each layer removes load from the one behind it.

Redis as database

Redis can persist data and has modules for search and other jobs, so some teams use it as a primary store for particular workloads. This is a deliberate design choice with careful sizing, persistence, and backup, and it is different from the usual cache role. For ordinary business data, a durable database remains the safer home.

Every design choice gives something and takes something. Be honest about both sides.

The central trade-off

The big trade-off is speed versus freshness. The longer you keep copies, the faster and cheaper your application becomes, and the more likely users are to see older information. Short lifetimes mean fresher data but a lower hit ratio. A good architect decides, for each kind of data, how stale is acceptable.

Speed versus cost

Memory is the most expensive kind of storage. Caching everything is not sensible. Cache what is costly to compute, read often, and changes rarely, and let the rest stay in the database.

Simplicity versus resilience

A single-node cache is simple and cheap, but a failure removes it. Replicated and zone-redundant setups are more resilient but cost more and need applications that handle reconnects. Match the choice to what an outage of the cache would cost the business.

Proven shapes to copy, and common shapes to avoid.

Patterns that work

Anti-patterns

An anti-pattern is a common solution that looks sensible but causes trouble. Here are the usual ones.

A practical list you can print and keep next to your desk.

Best practices

• Measure first. Find the repeated, costly operations before deciding what to cache.
• Name keys clearly. Use a consistent scheme with prefixes for the kind of data and a version marker so you can change formats safely.
• Always set a lifetime. Choose a TTL for every item, with a little random variation.
• Keep values small. Cache only what you need, and compress or split large data.
• Reuse connections. Use one shared client per application, and configure sensible timeouts and retries.
• Fail soft. Treat cache errors as misses, so the application survives cache problems.
• Choose the eviction policy on purpose and reserve memory for overhead.
• Pick the tier for the job. Use replicated tiers for production, and test failover and scaling events.
• Secure the cache. Use private networking, encrypted connections, identities where possible, and managed secrets.
• Keep the cache close. Put it in the same region as the application, and as near in the network as possible.
• Watch the hit ratio and memory and alert before they become problems.
• Test with realistic load before launch, including a cold cache and a failover.

Common mistakes

Four typical situations, described as illustrative examples, showing when the service fits.

The stories below are illustrative composites of the kinds of situations where teams commonly use a managed Redis cache. They are not claims about any particular company, but they reflect the reasoning real architects use.

Short answers to the questions beginners ask most often.

Everything important, in one place.

Azure Cache for Redis gives you a managed, in-memory data store that sits in front of your database and answers common questions in a blink. Data lives under keys, with lifetimes that keep it fresh and eviction rules that keep memory under control. Rich structures such as hashes, sets, and sorted sets let you solve sessions, counters, rankings, and light messaging with ease. Microsoft runs the machines, while you choose the tier, secure the access, shape the keys, and design your application to survive a missing or restarting cache.

Remember the comparison we began with: a notice board at the library’s front desk. It is wonderful when it holds the right notices, with dates on them, and when the staff know what to do if the board falls down. Treat Azure Cache for Redis the same way: pin up only what is asked for often, take notices down when they go stale, never keep the only copy of anything precious on the board, and keep an eye on how many visitors find their answer there.