Microsoft Azure — Azure Cache for Redis

Azure is Microsoft's cloud computing platform offering over 200 services. This article covers azure cache for redis with production-ready configurations, best practices, and hands-on examples.

Why Azure Cache for Redis?

In production, every millisecond of latency and every database query counts. Azure Cache for Redis provides an in-memory data store that offloads backend databases, reduces latency, and handles high-throughput workloads. It's not just a cache—it's a distributed, low-latency key-value store that supports data structures like lists, sets, sorted sets, and streams. For DevOps engineers, it's a critical component for scaling applications without rewriting architecture. Common use cases include session stores, API response caching, real-time leaderboards, and message brokering via Redis Pub/Sub. Azure manages the infrastructure, patching, and high availability, but you still need to configure it correctly to avoid pitfalls like data loss, connection storms, and memory pressure. This section sets the stage: understand the 'why' before the 'how'.

az redis create \
  --resource-group myResourceGroup \
  --name myCache \
  --location eastus \
  --sku Standard \
  --vm-size C1 \
  --enable-non-ssl-port \
  --redis-configuration "maxmemory-policy allkeys-lru" "maxmemory-reserved 100"

Connection Management and Retry Logic

Connecting to Redis from your application is straightforward, but naive connection code will fail under load. Azure Cache for Redis uses TLS on port 6380 (recommended) or non-TLS on 6379. Use StackExchange.Redis (C#) or redis-py (Python) with connection multiplexing—one connection shared across threads. Never create a new connection per request; that exhausts ports and causes timeouts. Implement retry logic with exponential backoff for transient failures like timeouts or connection drops. Azure's load balancer may reset idle connections after 10 minutes, so keep-alive is essential. Also, configure AbortOnConnectFail=false to avoid crashing on startup if Redis is temporarily unreachable. This section provides production-ready connection code.

using StackExchange.Redis;
using System;
using System.Threading.Tasks;

public class RedisConnection
{
    private static readonly Lazy<ConnectionMultiplexer> LazyConnection = new Lazy<ConnectionMultiplexer>(() =>
    {
        var config = new ConfigurationOptions
        {
            EndPoints = { "myCache.redis.cache.windows.net:6380" },
            Password = "your-access-key",
            Ssl = true,
            AbortOnConnectFail = false,
            ConnectTimeout = 5000,
            SyncTimeout = 5000,
            KeepAlive = 60,
            ReconnectRetryPolicy = new ExponentialRetry(5000),
            RetryCount = 3
        };
        return ConnectionMultiplexer.Connect(config);
    });

    public static ConnectionMultiplexer Connection => LazyConnection.Value;
    public static IDatabase Database => Connection.GetDatabase();

    public static async Task<string> GetAsync(string key)
    {
        try
        {
            var value = await Database.StringGetAsync(key);
            return value;
        }
        catch (RedisTimeoutException ex)
        {
            // Log and return null; caller handles cache miss
            Console.WriteLine($"Redis timeout: {ex.Message}");
            return null;
        }
    }
}

Data Expiration and Eviction Policies

Redis is memory-bound. Without an eviction policy, writes fail when memory is full. Azure Cache for Redis defaults to volatile-lru, which evicts keys with TTL set. For production, choose a policy that matches your use case: allkeys-lru for general caching, allkeys-lfu for hot-key protection, or noeviction for critical data (but then you must monitor memory). Set TTL on all cache entries to prevent stale data and allow eviction to work. Use maxmemory-reserved to reserve memory for system operations—Azure recommends 10% of maxmemory. This section explains policies and shows how to set them via Azure CLI or portal. Also, use the INFO command to monitor evictions and memory usage.

# Set eviction policy and reserved memory via Azure CLI
az redis update \
  --name myCache \
  --resource-group myResourceGroup \
  --set redisConfiguration.maxmemory-policy="allkeys-lru" \
  --set redisConfiguration.maxmemory-reserved="100"

# Verify with redis-cli
redis-cli -h myCache.redis.cache.windows.net -p 6380 -a <access-key> --tls CONFIG GET maxmemory-policy
# Output: 1) "maxmemory-policy" 2) "allkeys-lru"

# Monitor evictions
redis-cli -h myCache.redis.cache.windows.net -p 6380 -a <access-key> --tls INFO stats | grep evicted_keys
# Output: evicted_keys:0

Caching Strategies: Cache-Aside, Read-Through, and Write-Through

The most common caching pattern is cache-aside: on a read, check cache first; on miss, load from database and populate cache. For writes, update database and invalidate cache (or update cache). This pattern is simple and works for most apps. Read-through and write-through are less common because they require custom logic in the cache library. Azure Cache for Redis doesn't natively support these; you implement them in your application. For high consistency, consider write-through (update cache synchronously on write) but beware of increased write latency. For eventual consistency, cache-aside with TTL is sufficient. This section shows a cache-aside implementation in Python with retry and TTL. Also discuss stampeding herd problem and how to mitigate with locking or early recomputation.

import redis
import json
import time

r = redis.Redis(
    host='myCache.redis.cache.windows.net',
    port=6380,
    password='your-access-key',
    ssl=True,
    socket_connect_timeout=5,
    socket_timeout=5,
    retry_on_timeout=True,
    health_check_interval=30
)

def get_user(user_id):
    cache_key = f"user:{user_id}"
    # Try cache
    cached = r.get(cache_key)
    if cached:
        return json.loads(cached)
    # Cache miss: load from DB (simulated)
    user = query_database(user_id)
    if user:
        # Set with TTL 1 hour
        r.setex(cache_key, 3600, json.dumps(user))
    return user

def query_database(user_id):
    # Simulate DB call
    time.sleep(0.1)
    return {"id": user_id, "name": "Alice"}

# Usage
user = get_user(42)
print(user)

High Availability and Failover with Replication

Azure Cache for Redis Standard and Premium tiers provide a primary-replica pair. On primary failure, Azure automatically promotes the replica. However, this failover is not instantaneous—it can take 10-30 seconds. During that time, writes fail and reads may return stale data (if using replica reads). Your application must handle these transient errors with retry logic. Also, after failover, the new primary may have a cold cache (if persistence is not enabled). For Premium tier, you can enable data persistence (RDB or AOF) to minimize data loss. This section explains the failover process, how to test it (via Azure portal reboot), and how to configure your app to reconnect gracefully. Also discuss connection string changes: the endpoint remains the same, but the underlying IP changes.

using StackExchange.Redis;
using System;

public class ResilientRedis
{
    private static ConnectionMultiplexer _redis;
    private static readonly object _lock = new object();

    public static IDatabase GetDatabase()
    {
        if (_redis == null || !_redis.IsConnected)
        {
            lock (_lock)
            {
                if (_redis == null || !_redis.IsConnected)
                {
                    _redis?.Dispose();
                    _redis = Connect();
                }
            }
        }
        return _redis.GetDatabase();
    }

    private static ConnectionMultiplexer Connect()
    {
        var config = new ConfigurationOptions
        {
            EndPoints = { "myCache.redis.cache.windows.net:6380" },
            Password = "your-access-key",
            Ssl = true,
            AbortOnConnectFail = false,
            ConnectTimeout = 10000,
            SyncTimeout = 5000,
            KeepAlive = 60,
            ReconnectRetryPolicy = new ExponentialRetry(5000),
            RetryCount = 5
        };
        return ConnectionMultiplexer.Connect(config);
    }
}

Monitoring and Alerting with Azure Metrics and Insights

You can't fix what you don't measure. Azure Cache for Redis exposes metrics via Azure Monitor: cache hits/misses, evicted keys, server load, memory usage, connected clients, and operations per second. Set up alerts for high memory usage (>80%), high evictions (>0), and server load (>80%). Also use Redis's INFO command for deeper diagnostics: keyspace hits/misses, connected clients, and replication lag. For Premium tier, enable Redis Insights for slow log and latency monitoring. This section shows how to configure alerts via Azure CLI and how to query metrics programmatically. Also discuss using Application Insights to correlate Redis performance with application performance.

# Create metric alert for high memory usage
az monitor metrics alert create \
  --name "RedisHighMemory" \
  --resource-group myResourceGroup \
  --scopes /subscriptions/.../resourceGroups/myResourceGroup/providers/Microsoft.Cache/Redis/myCache \
  --condition "used_memory_percentage > 80" \
  --description "Alert when Redis memory usage exceeds 80%" \
  --evaluation-frequency 5m \
  --window-size 15m \
  --severity 2 \
  --action-groups /subscriptions/.../resourceGroups/myResourceGroup/providers/microsoft.insights/actionGroups/myActionGroup

# Query cache hits ratio
az monitor metrics list \
  --resource /subscriptions/.../resourceGroups/myResourceGroup/providers/Microsoft.Cache/Redis/myCache \
  --metric "cachehits" "cachemisses" \
  --interval PT5M \
  --output table

Scaling and Clustering for High Throughput

When a single Redis instance isn't enough, scale up (larger SKU) or scale out (clustering). Azure Cache for Redis Premium tier supports clustering, which shards data across multiple nodes using hash slots. This increases throughput linearly with shard count. However, clustering has limitations: multi-key operations (e.g., transactions, unions) only work if keys are in the same slot. Use hash tags to force related keys into the same slot. Scaling a cluster requires careful planning—Azure supports scaling up/down and adding/removing shards, but it's a long-running operation with potential data movement. This section explains how to enable clustering, choose shard count, and handle slot migration. Also discuss geo-replication for cross-region disaster recovery.

# Create a Premium cluster with 3 shards
az redis create \
  --resource-group myResourceGroup \
  --name myClusterCache \
  --location eastus \
  --sku Premium \
  --vm-size P1 \
  --shard-count 3 \
  --redis-configuration "cluster-enabled true"

# Scale cluster to 5 shards (update operation)
az redis update \
  --name myClusterCache \
  --resource-group myResourceGroup \
  --set shardCount=5

# Connect to cluster with redis-cli (use -c for cluster mode)
redis-cli -h myClusterCache.redis.cache.windows.net -p 6380 -a <access-key> --tls -c SET user:123 "Alice"
# Output: OK
redis-cli -h myClusterCache.redis.cache.windows.net -p 6380 -a <access-key> --tls -c GET user:123
# Output: "Alice"

Security: Access Keys, Firewall, and VNet Integration

Azure Cache for Redis uses access keys for authentication. Rotate them regularly and store them in Azure Key Vault, not in code. For network security, use firewall rules to restrict access to specific IP ranges or Azure services. For highest security, use VNet injection (Premium tier) to place the cache in your virtual network, accessible only from within the VNet. This prevents exposure to the public internet. Also enable TLS 1.2+ and disable non-SSL port. This section shows how to configure firewall rules and VNet integration via CLI. Discuss managed identity for passwordless access (preview). Also cover auditing via Azure Activity Logs.

# Add firewall rule to allow only your app's IP
az redis firewall-rules create \
  --resource-group myResourceGroup \
  --name myCache \
  --rule-name allowAppIP \
  --start-ip 203.0.113.1 \
  --end-ip 203.0.113.1

# Enable VNet integration (requires Premium SKU and existing subnet)
az redis update \
  --name myCache \
  --resource-group myResourceGroup \
  --set subnet.id="/subscriptions/.../resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVNet/subnets/mySubnet" \
  --set static-ip="10.0.0.4"

# Rotate access key
az redis regenerate-key \
  --name myCache \
  --resource-group myResourceGroup \
  --key-type Primary

# Store key in Key Vault
az keyvault secret set \
  --vault-name myVault \
  --name RedisPrimaryKey \
  --value $(az redis list-keys --name myCache --resource-group myResourceGroup --query primaryKey -o tsv)

Performance Tuning: Pipelining, Batching, and Compression

To maximize throughput, use pipelining to send multiple commands without waiting for each response. StackExchange.Redis supports this natively via async operations. For bulk data loads, use batching (e.g., MSET) instead of individual SETs. Also compress large values (e.g., JSON) before storing to reduce memory and network overhead. Use Redis's built-in compression? No—compress client-side with GZip or Snappy. This section provides code for pipelining and compression. Also discuss connection tuning: increase sync timeout for slow operations, but avoid long timeouts that mask issues. Use the SLOWLOG command to identify slow commands.

import redis
import json
import gzip

r = redis.Redis(
    host='myCache.redis.cache.windows.net',
    port=6380,
    password='your-access-key',
    ssl=True,
    socket_connect_timeout=5,
    socket_timeout=5,
    retry_on_timeout=True,
    health_check_interval=30
)

def compress_data(data):
    return gzip.compress(json.dumps(data).encode('utf-8'))

def decompress_data(compressed):
    return json.loads(gzip.decompress(compressed).decode('utf-8'))

# Pipeline example
pipe = r.pipeline()
for i in range(1000):
    pipe.setex(f"key:{i}", 3600, compress_data({"index": i, "value": "x" * 100}))
pipe.execute()  # Sends all commands at once

# Retrieve with pipeline
pipe = r.pipeline()
for i in range(1000):
    pipe.get(f"key:{i}")
results = pipe.execute()
for compressed in results:
    data = decompress_data(compressed)
    # process data
print("Done")

Disaster Recovery and Geo-Replication

For cross-region disaster recovery, Azure Cache for Redis Premium offers geo-replication, linking two caches as primary and secondary. Data is asynchronously replicated. On regional failure, you can promote the secondary to primary. However, geo-replication has limitations: no clustering support, and failover is manual (or automated with custom scripts). Also, data loss is possible due to async replication. This section explains how to set up geo-replication via CLI and how to handle failover. Discuss backup and restore options: RDB persistence for point-in-time recovery, and export/import for manual backup. For critical data, combine geo-replication with periodic exports to blob storage.

# Create primary cache in East US
az redis create --resource-group myResourceGroup --name primaryCache --location eastus --sku Premium --vm-size P1

# Create secondary cache in West US
az redis create --resource-group myResourceGroup --name secondaryCache --location westus --sku Premium --vm-size P1

# Link secondary to primary
az redis link create \
  --resource-group myResourceGroup \
  --name primaryCache \
  --server-to-link secondaryCache \
  --replication-role Secondary

# Promote secondary to primary (manual failover)
az redis link delete \
  --resource-group myResourceGroup \
  --name primaryCache \
  --server-to-link secondaryCache
# Then update application connection string to secondaryCache

# Export RDB backup
az redis export \
  --resource-group myResourceGroup \
  --name primaryCache \
  --container "https://mystorageaccount.blob.core.windows.net/backups" \
  --prefix "redis-backup" \
  --format rdb

Common Pitfalls and Production Anti-Patterns

Even experienced teams make mistakes. Common pitfalls include: using Redis as a primary database (data loss on failover), storing large objects without compression, ignoring eviction metrics, using too many connections, and not setting TTL. Also, avoid using Redis for complex queries—it's a key-value store, not a relational database. Another anti-pattern is using Redis for transient data that can be regenerated (e.g., computed results) without TTL. This section lists the top 5 anti-patterns with real-world examples and how to fix them. Also discuss the danger of using KEYS command in production (blocking). Use SCAN instead. Finally, emphasize that Redis is not a message queue replacement for high durability—use Azure Service Bus or Event Hubs for that.

# Bad: KEYS blocks the server
redis-cli -h myCache.redis.cache.windows.net -p 6380 -a <access-key> --tls KEYS user:*
# Good: SCAN is non-blocking
redis-cli -h myCache.redis.cache.windows.net -p 6380 -a <access-key> --tls SCAN 0 MATCH user:* COUNT 100
# Output: 1) "0" 2) (empty list or set of keys)

Cost Optimization and Right-Sizing

Azure Cache for Redis costs can spiral if not managed. Choose the smallest SKU that meets your throughput and memory needs. Use the Azure Pricing Calculator to estimate costs. For dev/test, use Basic or Standard C0. For production, start with Standard C1 and scale up as needed. Consider reserved instances for 1-3 year terms to save up to 55%. Also, use clustering to scale out instead of scaling up to very large SKUs (which have diminishing returns). Monitor cache metrics to right-size: if server load is below 20%, consider scaling down. If evictions are high, scale up or optimize TTL. This section provides a decision tree for SKU selection and cost-saving tips.

# Estimate cost for Standard C1 (1 GB) in East US
az redis list-skus --location eastus --output table
# Output shows SKU details and prices

# Get current cache metrics for right-sizing
az monitor metrics list \
  --resource /subscriptions/.../resourceGroups/myResourceGroup/providers/Microsoft.Cache/Redis/myCache \
  --metric "usedmemorypercentage" "serverload" \
  --interval PT1H \
  --output table