Redis cache - Azure Glossary

Understand the concept

In plain English

A Redis cache is a fast in-memory store that applications use when a database, API, or computation is too slow to hit every time. It commonly holds session data, rate-limit counters, feature flags, short-lived lookup results, queues, or personalization hints. In Azure, Redis is managed as a cache resource with sizing, networking, authentication, monitoring, and scaling choices. It improves speed, but it should not become a hidden system of record unless the application is designed for that risk.

Why it matters

Redis cache matters because many cloud applications are limited less by compute and more by repeated calls to slower dependencies. A well-designed cache can make pages load faster, reduce database pressure, absorb traffic spikes, and improve user experience during busy periods. A poorly designed cache can hide stale data, create authentication exposure, or fail in ways that overload the primary database. The real value is disciplined caching: choose data with clear freshness rules, size the cache for memory and throughput, secure the endpoint, monitor evictions, and keep the application able to rebuild state when cached values disappear. Monitoring keeps that balance visible.

Official wording and source

A Redis cache on Azure is a managed in-memory data store based on Redis technology, used by applications to read and write frequently accessed data with low latency. Azure offers Redis capabilities through Azure Cache for Redis and Azure Managed Redis service families.

Open Microsoft Learn

Technical context

In Azure architecture, a Redis cache sits in the data platform and application performance layer. App Service, AKS, Functions, VMs, and API services connect to it through Redis clients over secured endpoints. Azure manages the cache resource, while teams choose tier, capacity, clustering, private networking, authentication, diagnostics, and persistence or replication options where supported. The cache often fronts Azure SQL, Cosmos DB, storage, search, or external APIs. Operators treat it as a dependency with metrics for memory, server load, connections, latency, evictions, and cache hit ratio.

Exam context

Compare with

Azure Managed Redis Database

Where it is used

Where you see it

The Azure portal Overview and Monitoring blades show Redis cache status, host name, ports, tier, memory pressure, server load, connections, and cache metrics during operations review.
Application configuration contains Redis host names, ports, authentication settings, Key Vault references, or managed identity settings used by client libraries during deployment troubleshooting during application deployment troubleshooting.
Azure Monitor alerts, Application Insights traces, and database metrics reveal cache misses, evictions, reconnect storms, or backend load spikes tied to Redis behavior during performance triage.

Common situations

Reduce repeated database reads for product catalogs, profile fragments, or reference data that can tolerate a clear expiration policy.
Store short-lived session or personalization state close to web and API workloads while keeping durable records elsewhere.
Absorb traffic spikes by serving hot keys from memory instead of scaling the primary database for every read burst.
Support rate limiting, feature flags, distributed locks, or queue-like patterns only when the failure and expiry behavior is understood.
Compare Azure Cache for Redis and Azure Managed Redis options during migration, modernization, or global latency planning.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 News publisher speeds election-night results pages Scenario, objectives, solution, measured impact, and takeaway.

Scenario

A national news publisher expected millions of readers during election-night coverage. The results API depended on database reads that were too expensive to serve for every page refresh.

Goals

Reduce page-load latency during traffic spikes.
Protect the results database from repeated identical reads.
Keep official vote totals in the database, not the cache.
Monitor freshness and cache hit ratio throughout the event.

Approach using Redis cache

The engineering team placed a Redis cache between the results API and Azure SQL Database. Vote totals and race summaries were cached with short TTLs, while the database remained the source of truth. App Service instances reused Redis connections and used Key Vault references for authentication secrets. Azure Monitor dashboards tracked hit ratio, evictions, connections, server load, and API latency. A fallback path allowed the API to query SQL if a key expired or Redis became unavailable. Operators rehearsed cache flush and warmup using a staging traffic replay before election week.

Potential outcomes

Median results-page latency dropped from 420 milliseconds to 65 milliseconds.
Database read load during peak refresh periods fell by 78 percent.
No official vote total was trusted solely from Redis because SQL remained authoritative.
Editors saw freshness alerts when cache age exceeded the agreed threshold.

What to learn

A Redis cache delivers value when it accelerates hot reads without replacing the durable source of truth.

Scenario 02 Banking fraud platform caches risk features safely Scenario, objectives, solution, measured impact, and takeaway.

Scenario

A digital banking platform calculated fraud-risk features from several backend systems. Recomputing every feature for every card transaction increased authorization latency during shopping peaks.

Goals

Lower transaction-risk lookup latency under peak load.
Expire cached features before they became misleading.
Avoid storing raw card data in Redis.
Prove cache behavior to risk and compliance teams.

Approach using Redis cache

The fraud engineering team used a Redis cache for short-lived, derived risk features such as velocity counters and merchant-category aggregates. Raw card numbers and customer secrets never entered the cache. Each feature used a TTL aligned to the risk model, and cache misses fell back to durable event and account stores. Private networking, TLS, and managed secrets protected the Redis endpoint. Azure Monitor and Application Insights tracked p95 lookup latency, hit ratio, eviction rate, and backend fallback calls. Compliance reviewers received diagrams showing data classification, TTLs, and source-of-truth boundaries.

Potential outcomes

p95 risk-feature lookup latency improved from 145 milliseconds to 28 milliseconds.
Authorization backend calls dropped 52 percent during holiday shopping traffic.
No raw payment data was stored in the Redis cache.
Risk reviewers approved the design because every cached feature had a documented TTL and fallback source.

What to learn

Redis cache can support regulated workloads when teams cache derived, expiring data and keep sensitive records elsewhere.

Scenario 03 Construction software vendor retires oversized cache fleet Scenario, objectives, solution, measured impact, and takeaway.

Scenario

A construction project-management vendor had created separate Redis caches for many customer-facing modules. Several caches were oversized, lightly used, and missing owner tags after a product reorganization.

Goals

Reduce unnecessary Redis spend without hurting active modules.
Find caches with low hit ratio or no recent connections.
Tag remaining caches with owners and environments.
Choose candidates for Azure Managed Redis migration.

Approach using Redis cache

The platform operations team used Azure CLI and Azure Monitor exports to inventory Redis cache resources by SKU, region, tags, connections, memory, operations, and hit ratio. Caches with no active owner were matched to application repositories and deployment records. Three unused development caches were deleted, two production caches were downsized after load testing, and high-value modules were marked for Azure Managed Redis evaluation. The team added diagnostic settings and budget tags to every remaining cache. Application teams documented the source of truth and fallback behavior for each retained cache.

Potential outcomes

Monthly Redis spend fell by 31 percent without a customer-facing incident.
All remaining production caches had owner, environment, and cost-center tags.
Two modules moved to a better-sized cache tier after peak-load testing.
Migration planning focused on six valuable caches instead of the entire unmanaged fleet.

What to learn

Redis cache cost control starts with proving which caches improve application behavior and which only preserve old architecture decisions.

Azure CLI

Azure CLI is useful for Redis cache work because cache problems often cross resource, network, and application boundaries. I use CLI to inventory caches, show SKU and provisioning state, inspect firewall rules, check identities, list or rotate keys when approved, and export evidence during incidents. The portal is convenient for charts, but CLI gives repeatable checks across subscriptions and environments. It also supports automation for scaling, migration assessment, tagging, diagnostics review, and cleanup of forgotten caches that keep billing after the application has moved on. That repeatability is especially helpful when many teams own caches across multiple subscriptions. Use evidence now.

Useful for

List Redis caches across a resource group or subscription to find ownership, SKU, region, and stale resources.
Show a specific cache before troubleshooting latency, connection failures, authentication mode, or unexpected provisioning state.
Inspect firewall rules or private endpoint configuration when applications cannot connect from an expected subnet.
Scale or update a cache after confirming memory pressure, server load, and business approval for the cost change.
Export cache metadata for migration planning from Azure Cache for Redis to Azure Managed Redis.

Before you run a command

Confirm tenant, subscription, resource group, cache name, region, service family, SKU, capacity, and intended environment.
Check whether commands use az redis for Basic, Standard, or Premium, or az redisenterprise for Managed or Enterprise-style resources.
Understand whether the action is read-only, scaling, key exposure, key regeneration, flush, delete, or another destructive operation.
Verify network path, private endpoint, firewall, identity, access keys, and TLS requirements before blaming application code.
Plan output format, cost impact, rollback, monitoring, and application restart behavior before changing cache settings.

What the output tells you

Provisioning state and resource ID confirm whether the Redis cache exists, is updating, or is ready for client connections.
SKU, capacity, region, and shard-related fields explain performance limits, available features, and expected cost posture.
Host name, SSL port, non-SSL settings, and network rules tell operators how clients are expected to reach the cache.
Identity and access-key settings show whether clients authenticate through Entra-based access, shared keys, or legacy configuration.
Diagnostic and metric configuration reveals whether enough telemetry exists to troubleshoot latency, evictions, and connection issues.

Mapped commands

Redis cache CLI Commands

az redis list --resource-group <resource-group>

az redisdiscoverDatabases

az redis show --name <cache-name> --resource-group <resource-group>

az redisdiscoverDatabases

az redis update --name <cache-name> --resource-group <resource-group> --set <property>=<value>

az redisconfigureDatabases

az redis firewall-rules list --name <cache-name> --resource-group <resource-group>

az redis firewall-rulesdiscoverDatabases

az redisenterprise list --resource-group <resource-group>

az redisenterprisediscoverDatabases

az redisenterprise show --name <cache-name> --resource-group <resource-group>

az redisenterprisediscoverDatabases

az redisenterprise update --cluster-name <cache-name> --resource-group <resource-group> --sku <sku-name>

az redisenterpriseconfigureDatabases

Architecture context

A senior Azure architect places a Redis cache close to the application path that needs low latency, then designs the failure mode before celebrating the speed. The key questions are what data goes into Redis, how long it lives, who can write it, and what happens when it is missing. The resource design includes SKU, region, capacity, private endpoint or firewall, Entra or key-based authentication, diagnostics, and scaling. For global systems, active geo-replication or regional cache copies may matter. For simpler systems, a single well-monitored cache with safe fallback can be the right answer. The cache contract should be written beside the application contract.

Security: Security impact is direct because Redis often holds data that applications trust. Even when values are temporary, they may include session identifiers, profile fragments, rate-limit state, or business decisions. Secure the cache with TLS, private networking where appropriate, limited management permissions, and strong authentication. Prefer Microsoft Entra authentication when supported; protect access keys as secrets when keys remain enabled. Avoid storing raw tokens, passwords, or sensitive personal data unless there is a clear design and retention reason. Monitor diagnostic logs and connection patterns so unexpected clients are detected before cached data becomes an attack path. Review connection logs regularly so unknown clients are not normalized as background noise.
Cost: Cost is tied to tier, capacity, replicas, clustering, persistence, active geo-replication, monitoring, and cross-region data movement. A cache that is too small causes evictions and poor performance; a cache that is too large wastes money every hour. The right FinOps posture is to measure memory pressure, hit ratio, peak load, and application value. Caching can reduce database and API cost by avoiding repeated expensive calls, but it can also add another always-on service. Review idle caches, oversized SKUs, low hit ratios, and duplicate regional deployments that no longer match business traffic. Retire unused caches quickly because always-on memory capacity charges whether it helps users or not.
Reliability: Reliability impact depends on how the application treats the cache. If Redis is only a performance layer, cache loss should slow the app but not corrupt business state. If Redis stores sessions, locks, or coordination data, outages can become user-visible quickly. Reliable designs include retry policies, connection-pool tuning, fallback to the system of record, cache warmup, health checks, and clear TTL choices. Premium, Enterprise, Azure Managed Redis, clustering, persistence, or geo-replication options may improve continuity, but they do not replace application-level resilience. Operators should rehearse cache restart, scale, failover, and secret-rotation scenarios. Cache resilience should be validated with drills, not assumed from the selected tier alone.
Performance: Performance is the core reason to use a Redis cache. Keeping hot data in memory can reduce latency from tens or hundreds of milliseconds to a few milliseconds when clients, networking, and serialization are designed well. Throughput depends on SKU, shard count, clustering policy, payload size, connection reuse, command patterns, and client location. Poor TTL choices, large values, blocking commands, connection churn, or cross-region access can erase the benefit. Measure p95 latency, hit ratio, server load, evictions, and backend database load together. A fast cache with a bad data model still creates slow applications. Client-side connection reuse and payload discipline matter as much as the Azure SKU.
Operations: Operators manage a Redis cache by watching memory, server load, CPU, connections, network throughput, operations per second, errors, evictions, and cache hit ratio. They inspect SKU and capacity before assuming code is the problem. They also review firewall or private endpoint settings, authentication mode, access keys or Entra policies, patch schedules, diagnostics, and application connection strings. Operational tasks include scaling, rotating keys, testing failover, clearing test data, troubleshooting latency, and documenting data ownership. Good teams know which application owns each cache and which database or service can rebuild the cached content. Operators should also keep ownership tags current so incidents reach the right application team.

Common mistakes

Treating Redis as the durable system of record without designing persistence, rebuild, or fallback behavior.
Sizing only for average memory and ignoring peak load, hot keys, eviction policy, and connection count.
Leaving public access, shared keys, or non-TLS options enabled because a test connection was easier that way.
Caching stale business decisions without TTL, invalidation, or a source-of-truth reconciliation path.
Forgetting to delete or downsize old caches after migration, leaving always-on cost with no application value.