Azure Cache for Redis for Low-Latency Data

Azure Cache for Redis is a fully managed, in-memory data store based on the open-source Redis (REmote DIctionary Server) engine. It provides extremely low latency (typically <1 millisecond) for data access by storing data in RAM rather than on disk. It is commonly used as a cache layer between applications and backend databases (like Azure SQL Database or Cosmos DB) to reduce latency and database load, but it can also serve as a session store, message broker, or real-time analytics engine.

Databases store data on disk or SSD, which has access times measured in milliseconds (5-10 ms for SSD, 50-100 ms for HDD). Even with indexing, reading from disk involves physical I/O and is slower than reading from RAM. A cache like Redis keeps frequently accessed data in memory, reducing read latency to microseconds. This is critical for applications that require fast response times, such as e-commerce product catalogs, gaming leaderboards, or real-time dashboards. Additionally, caching reduces the load on the backend database, allowing it to handle more concurrent users or reducing the need for expensive scaling.

Azure Cache for Redis stores data as key-value pairs. The key is a unique string identifier, and the value can be a string, list, set, sorted set, hash, bitmap, or other Redis data structures. When an application requests data, it first checks the cache. If the data is present (cache hit), Redis returns it instantly. If not (cache miss), the application retrieves the data from the database, then stores a copy in the cache for future requests. This pattern is called the cache-aside pattern, and it is the most common caching strategy.

#### Cache-Aside Pattern (Lazy Loading)

This pattern ensures that only frequently accessed data is cached, and stale data is automatically removed after the TTL expires.

- Tiers: Azure Cache for Redis offers three tiers: - Basic: Single node, no SLA, suitable for dev/test. - Standard: Two nodes (primary/replica), 99.9% SLA. - Premium: Two nodes plus additional features like data persistence, clustering, and VNet injection. - Memory Sizes: From 250 MB (Basic C0) up to 120 GB (Premium P5). - Eviction Policies: When memory is full, Redis evicts keys based on the configured policy. Default is volatile-lru (evict keys with TTL set using LRU). Other policies include allkeys-lru, volatile-ttl, volatile-random, allkeys-random, noeviction (returns errors on write). - Time-to-Live (TTL): Optional expiration time set on each key. After TTL expires, the key is automatically deleted. Default is no expiration. - Persistence: Premium tier offers RDB (snapshot) and AOF (append-only file) persistence to disk for durability. - Clustering: Premium tier supports clustering to distribute data across up to 10 shards, allowing caches larger than 120 GB. - Geo-replication: Premium tier supports geo-replication for cross-region disaster recovery.

In the Azure portal, you can create a new Redis cache by specifying:

To connect from an application, you need the hostname and access key. Example connection string for StackExchange.Redis client (C#):

mycache.redis.cache.windows.net:6380,password=yourkey,ssl=True,abortConnect=False

To verify connectivity, you can use the Redis CLI (if installed) or the built-in Console in the Azure portal:

redis-cli -h mycache.redis.cache.windows.net -p 6380 -a yourkey --tls

Then run commands like:

PING
SET mykey "Hello"
GET mykey
TTL mykey

SET key value [EX seconds] [PX milliseconds] [NX|XX]
GET key
DEL key
EXPIRE key seconds
TTL key
KEYS pattern (avoid in production)

Azure Cache for Redis is a powerful tool for reducing latency and database load. It stores data in memory, uses key-value pairs, supports various data structures, and offers configurable eviction policies and TTL. The cache-aside pattern is the primary integration pattern. For DP-900, focus on understanding when to use caching, the cache-aside pattern, and the default eviction policy.

A major online retailer uses Azure Cache for Redis to cache product details (name, price, description, images) for their top 10,000 products. The backend is Azure SQL Database with millions of products. Without caching, each product page load triggers a database query, causing 50-100 ms latency and high DTU consumption. By implementing cache-aside with a 10-minute TTL, the application achieves <5 ms latency for cached products, serving 90% of requests from cache. The database load drops by 80%, allowing the retailer to handle Black Friday traffic without scaling up. The cache is deployed in the Premium tier with 10 GB memory and geo-replication to a secondary region for disaster recovery. Misconfiguration: initially, they set TTL to 24 hours, causing stale prices during a flash sale. They reduced TTL to 5 minutes and added a cache invalidation trigger when prices are updated in the database.

A gaming company uses Azure Cache for Redis to maintain real-time leaderboards for millions of players. Redis sorted sets (ZADD, ZRANK) allow O(log N) operations for updating scores and retrieving rankings. The cache runs in Standard tier with 5 GB memory. Players' scores are updated every few seconds, and the top 100 leaderboard is refreshed every 10 seconds. The cache reduces latency from 20 ms (if using SQL) to <1 ms. They also use Redis Pub/Sub to broadcast leaderboard changes to game servers. Performance consideration: they monitor evicted keys and adjust memory size to avoid frequent evictions of top players' data. Common mistake: using a single large sorted set for all players; they shard by game region to distribute load.

A SaaS provider hosts a multi-tenant web application on Azure App Service. They use Azure Cache for Redis as a session state provider via the ASP.NET Redis Session State Provider. User session data (cart items, preferences) is stored in Redis with a 20-minute sliding expiration. This allows any web server instance to serve any user, enabling horizontal scaling. Without Redis, session data was stored in memory on each web server, causing session loss during scale-out or restarts. They chose Standard tier with 1 GB memory for 10,000 concurrent users. Misconfiguration: they initially used the Basic tier, which has no SLA and caused session loss during patching. They upgraded to Standard for high availability. They also set abortConnect=false in the connection string to prevent application crashes if Redis is temporarily unavailable.