Azure Cache for Redis

Azure Cache for Redis is a fully managed, in-memory caching service based on the open-source Redis (Remote Dictionary Server) engine. It provides a high-performance, low-latency data store that keeps data in memory (RAM) rather than on disk, enabling sub-millisecond read and write operations. The primary business problem it solves is the latency and throughput bottleneck caused by repeatedly fetching the same data from a slower backend database or external API. In many applications, a small percentage of data (e.g., product catalog, user sessions, configuration settings) is accessed frequently. Without a cache, every request hits the database, increasing response times and database load, leading to higher costs and poor user experience. Azure Cache for Redis alleviates this by storing frequently accessed data in memory, so subsequent requests can be served instantly without touching the database. It also enables use cases like session management, real-time leaderboards, message brokering, and distributed locking.

Azure Cache for Redis operates as a key-value store. Data is stored as a key (a string) and a value (which can be a string, hash, list, set, sorted set, or other data structures). When an application needs data, it first checks the Redis cache. If the data exists (a cache hit), it is returned immediately. If not (a cache miss), the application fetches the data from the primary database, stores it in the cache for future requests, and then returns it. This pattern is called 'lazy loading' or 'cache-aside'. The application is responsible for managing cache invalidation—updating or removing cached data when the underlying data changes. Azure Cache for Redis does not automatically synchronize with the database; it is a passive cache. To keep the cache fresh, developers often set a time-to-live (TTL) on cached items, after which the item expires and is automatically removed. Redis uses an eviction policy (like Least Recently Used – LRU) when memory is full, to make room for new items.

Azure Cache for Redis offers several tiers:

Pricing is based on tier, memory size (GB), and data transfer. The Basic tier is cheapest but has no SLA. Standard is most common for production. Premium adds cost for clustering, persistence, and VNet. Enterprise is the most expensive.

On-premises, you would deploy a Redis server (open-source) on a VM or bare metal. You'd manage installation, configuration, patching, backups, monitoring, scaling, and failover manually. Azure Cache for Redis abstracts all that: you provision a cache instance via the portal, CLI, or ARM template, and Azure handles the underlying infrastructure, patching, replication, and failover (in Standard and above). On-premises, you have full control but higher operational overhead. Azure Cache for Redis also integrates natively with Azure services like App Service, Functions, and Azure SQL, making it easier to adopt in cloud-native architectures. The trade-off is that you cannot modify the Redis configuration file (redis.conf) directly—you can only configure a subset of parameters via Azure's management interface.

In the Azure portal, you can create a cache instance by searching for 'Azure Cache for Redis' and clicking 'Create'. You specify DNS name, subscription, resource group, location, tier, and memory size. After deployment, you get a hostname (e.g., mycache.redis.cache.windows.net) and access keys. You can configure advanced settings like clustering, persistence, and firewall rules. The portal provides monitoring metrics (hits, misses, evictions, CPU, memory) and a console to run Redis commands.

Using the Azure CLI, you can create a cache with:

az redis create \
  --resource-group myResourceGroup \
  --name myCache \
  --location eastus \
  --sku Standard \
  --vm-size C0

To list access keys:

az redis list-keys --resource-group myResourceGroup --name myCache

For Bicep/ARM templates, you define a Microsoft.Cache/Redis resource with properties like sku (name, family, capacity) and enableNonSslPort.

Consider an e-commerce website with a product catalog stored in Azure SQL Database. Without caching, every page load queries the database, causing high latency and database load during peak shopping seasons. By adding Azure Cache for Redis, the product details (name, price, image URL) are cached with a TTL of 5 minutes. Cache hit rates exceed 90%, reducing database queries by 90% and page load times from 500ms to 10ms. Another scenario: a gaming platform needs real-time leaderboards. Redis sorted sets allow efficient ranking updates and retrieval. A third scenario: a microservices application uses Redis as a message broker with Pub/Sub patterns to decouple services.

A large online retailer uses Azure SQL Database to store product details (name, price, description, images). During Black Friday, traffic spikes to 100,000 requests per second. Without caching, each product page load queries the database, resulting in high latency (average 800ms) and database CPU at 95%, causing timeouts. The team deploys Azure Cache for Redis Standard tier (C6 – 53GB) in the same region as the app. They implement cache-aside with a TTL of 5 minutes for product details. Cache hit ratio reaches 95%, reducing database queries by 95%. Page load times drop to 50ms, and database CPU falls to 30%. The cache costs approximately $500/month, but the savings in database scaling and improved user experience justify the expense. They also configure eviction policy to 'allkeys-lru' to handle memory pressure gracefully.

A Software-as-a-Service (SaaS) company runs a multi-tenant web application on Azure App Service. User session data (e.g., shopping cart, login status) is stored in-memory on the web server, but when the app scales out to multiple instances, sessions are lost on a different server. They migrate session storage to Azure Cache for Redis using ASP.NET Session State Provider. Now any web server can retrieve the same session data. The cache is configured with data persistence (AOF) in Premium tier to avoid data loss on restart. They set a TTL of 20 minutes for sessions. The cache handles 10,000 concurrent users with 1GB memory. Cost is around $150/month. If they had used a traditional SQL database for sessions, latency would be higher and costs would be similar but with more administrative overhead.

A mobile game company needs a real-time leaderboard that updates as players score points. They use Azure Cache for Redis with sorted sets. Each player's score is stored as a member with a score. The leaderboard is retrieved using ZREVRANGE (highest to lowest). The cache is deployed in Standard tier with 2GB memory. The application updates scores on each game event, and the leaderboard is refreshed every second. Redis handles 50,000 updates per second with sub-millisecond latency. If they had used a relational database, the leaderboard query would be slow and expensive. They also use Redis Pub/Sub to broadcast leaderboard changes to connected clients. The total cache cost is $200/month. A common mistake is not setting a max memory limit, causing evictions of important data; they set maxmemory to 80% of available memory and use volatile-lru eviction.

Common misconfigurations include: (1) Using Basic tier in production – no replication means cache is lost on a reboot, causing a cold start. (2) Not setting a TTL – cache grows unbounded, eventually exhausting memory and causing evictions. (3) Using the same cache for multiple different data types without key prefixing, leading to key collisions. (4) Not enabling SSL – data in transit is unencrypted. (5) Firewall too permissive – exposes cache to potential attacks. (6) Ignoring eviction metrics – high evictions indicate cache is too small, causing frequent cache misses and defeating the purpose.