Cache-Aside Pattern with Azure Cache for Redis

The cache-aside pattern (also known as lazy loading) is a caching strategy where the application code explicitly manages the cache. The application first checks the cache for data. If found (cache hit), the data is returned directly. If not found (cache miss), the application retrieves the data from the primary data store (e.g., Azure SQL Database, Cosmos DB), stores it in the cache, and then returns it. The cache is not automatically synchronized with the data store; the application is responsible for populating and invalidating cache entries.

This pattern is ideal for read-heavy workloads where data is accessed frequently but updated infrequently. It reduces latency and load on the backend database by serving repeated requests from the faster cache tier.

Consider an e-commerce application that displays product details. The flow is: 1. Application receives a request for product ID 123. 2. Application calls cache.Get("product:123") on the Redis cache. 3. If the key exists, Redis returns the serialized product data (e.g., JSON). The application deserializes it and returns the response. This is a cache hit. 4. If the key does not exist (cache miss), the application queries the database: SELECT * FROM Products WHERE Id = 123. 5. The application receives the result, serializes it, and calls cache.Set("product:123", serializedData, expiryTime) to populate the cache. 6. The application returns the data to the client.

Key characteristics:

Azure Cache for Redis tiers: - Basic: Single node, no SLA, not for production. - Standard: Two nodes (primary/replica), 99.9% SLA. - Premium: Includes data persistence, clustering, and VNet support. - Enterprise/Enterprise Flash: Supports Redis modules like RediSearch and RedisBloom.

Default configuration values: - maxmemory-policy: Default is volatile-lru (evict keys with TTL set using LRU). Other policies: allkeys-lru, volatile-ttl, noeviction. - timeout: Default 0 (no timeout). - databases: Default 16.

TTL best practices: - Set TTL to a value that balances freshness and performance. Common values: 300 seconds (5 minutes) for frequently changing data, 3600 seconds (1 hour) for stable reference data. - Use SETEX command to set key with expiry in one atomic operation.

Cache invalidation strategies: - TTL-based: Data expires automatically. - Event-driven: When data is updated, publish a message (e.g., via Azure Event Grid) to invalidate the cache. - Write-through: Application updates the cache synchronously when writing to the database (combine with cache-aside for reads).

Using StackExchange.Redis (C#):

IDatabase cache = Connection.GetDatabase();
string key = "product:123";
string cachedData = cache.StringGet(key);
if (cachedData != null)
{
    return Deserialize<Product>(cachedData);
}
else
{
    Product product = await database.GetProductAsync(123);
    string serialized = Serialize(product);
    cache.StringSet(key, serialized, TimeSpan.FromMinutes(10));
    return product;
}

Using redis-cli:

redis-cli -h mycache.redis.cache.windows.net -p 6380 -a <access-key>
# Check if key exists
EXISTS product:123
# Get value
GET product:123
# Set key with TTL
SETEX product:123 600 "{\"id\":123,\"name\":\"Widget\"}"
# Delete key
DEL product:123

Monitoring commands: - INFO stats – shows cache hits/misses. - MONITOR – real-time command stream (avoid in production).

A large online retailer uses Azure Cache for Redis to cache product details, pricing, and inventory status. The product database is Azure SQL Database with millions of SKUs. The application implements cache-aside with a TTL of 5 minutes for product details and 1 minute for inventory (which changes more frequently). During a flash sale, traffic spikes to 100,000 requests per second. Without caching, the SQL database would be overwhelmed (it can handle about 10,000 QPS). With cache-aside, the cache hit ratio exceeds 95%, reducing database load to 5,000 QPS. The cache is a Premium tier with clustering (6 shards) to handle the throughput. A common misconfiguration is not setting a TTL, causing stale prices to be served for hours after a sale ends. The engineering team monitors cache hit rate and eviction rate using Azure Monitor; if evictions increase, they add more cache capacity.

A social media platform aggregates posts from multiple sources into a user feed. The feed data is stored in Azure Cosmos DB (API for MongoDB). The application uses cache-aside with Redis to cache the aggregated feed for each user. The cache key is 'feed:{userId}'. TTL is set to 60 seconds because feeds change frequently. When a user posts, the application invalidates the feeds of all followers (a fan-out operation) by deleting their cache keys. This is done asynchronously using Azure Functions. A pitfall is the 'thundering herd' problem: when a popular user posts, many followers' cache keys expire simultaneously, causing a flood of cache misses. The team mitigates this by using a mutex lock (SETNX) to allow only one request per user to regenerate the feed. They also use Redis Streams to queue invalidation events.

A trading platform caches real-time stock quotes using Azure Cache for Redis. Data comes from a third-party API and is stored in Azure SQL Database for historical analysis. The cache-aside pattern is used for low-latency reads. TTL is set to 2 seconds to ensure quotes are never more than 2 seconds old (acceptable for the application). The database is updated every second via a separate process. The application uses a write-through approach for cache updates on the rare occasions it writes data (e.g., user preferences), but for quotes, it relies on TTL expiry. A common failure is network latency between the application and Redis; they deploy Redis in a Premium tier with VNet injection to minimize latency. They also use Redis Cluster to distribute load across multiple nodes. Misconfiguration of the eviction policy (e.g., using 'noeviction' without enough memory) leads to write failures, causing cache updates to fail silently.