Redis Cache Patterns: Cache-Aside, Session, Pub/Sub

How it works internally: 1. Application requests data from cache (e.g., a Redis key). 2. If the key exists (cache hit), Redis returns the value immediately. 3. If the key does not exist (cache miss), the application retrieves the data from the database, writes it into the cache with a Time-To-Live (TTL), and then uses the data. 4. Subsequent requests for the same key will hit the cache until the TTL expires or the data is evicted.

Key components and defaults: - TTL (Time-To-Live): Default is no expiration if not set. Common practice: set TTL to 5-60 minutes depending on data volatility. On Azure Cache for Redis, the EXPIRE command sets TTL in seconds. - Memory eviction policies: When memory is full, Redis evicts keys based on the maxmemory-policy setting. Default is noeviction (returns errors on writes). Common alternatives: allkeys-lru (evicts least recently used keys), volatile-lru (evicts keys with TTL set using LRU). - Serialization: Data stored in Redis is binary-safe strings. Complex objects must be serialized (e.g., JSON, Protocol Buffers).

Configuration and verification commands: - Connect to Redis using redis-cli or StackExchange.Redis in .NET. - Set a key with TTL: SET mykey "value" EX 3600 (expires in 1 hour). - Check TTL: TTL mykey returns -2 if key does not exist, -1 if no expiry, positive integer for seconds remaining. - Monitor evictions: INFO stats shows evicted_keys count.

How it interacts with related technologies: - Azure SQL Database: Typical combination. Application uses Entity Framework or ADO.NET to query SQL, then caches results in Redis. - Cosmos DB: Similar pattern; cache read-heavy queries to reduce RU consumption. - Consistency considerations: Cache-Aside does not automatically invalidate on writes. Applications must update or delete cache entries when data changes to avoid stale reads.

How it works internally: 1. When a user first visits the application, a unique session ID (e.g., a cookie) is generated. 2. Session data (e.g., shopping cart, user preferences) is stored in Redis with the session ID as the key. 3. On subsequent requests, the application reads the session ID from the request, retrieves the data from Redis, and uses it. 4. Session data can be set to expire after a period of inactivity (e.g., 20 minutes).

Key components and defaults: - Session ID: Typically a GUID or random string. Stored in a cookie (e.g., ASP.NET_SessionId) or in the URL. - Session timeout: Default is 20 minutes in ASP.NET. Configured using SessionState provider. - Data serialization: Same as Cache-Aside; session objects must be serializable. - Redis data type: Usually a Redis Hash or String. Hash allows storing multiple fields (e.g., username, role) under one key.

Configuration and verification commands: - In ASP.NET Core, configure Redis session state in Startup.cs:

services.AddStackExchangeRedisCache(options =>
  {
      options.Configuration = "your-redis-connection-string";
  });
  services.AddSession(options =>
  {
      options.IdleTimeout = TimeSpan.FromMinutes(20);
      options.Cookie.HttpOnly = true;
  });

How it interacts with related technologies: - Azure App Service: Session caching enables sticky-session-free load balancing. Without it, users would lose session on server restart or scale-out. - Traffic Manager / Application Gateway: Any load balancer works because session data is external. - SignalR: For real-time web features, SignalR can use Redis backplane for scaling out, but session caching is separate.

How it works internally: 1. A subscriber connects to Redis and issues SUBSCRIBE channelname. 2. A publisher connects and issues PUBLISH channelname "message". 3. Redis forwards the message to all currently connected subscribers of that channel. 4. If a subscriber is not connected at the time of publish, it misses the message.

Key components and defaults: - Channels: String names. Pattern subscriptions (e.g., news.*) are supported using PSUBSCRIBE. - Message delivery: At most once. No acknowledgment, no retry. - Maximum message size: 512 MB (same as Redis string value). - Number of subscribers: No hard limit, but performance degrades with many subscribers due to fan-out.

Configuration and verification commands: - Subscribe: SUBSCRIBE mychannel (blocks). - Publish: PUBLISH mychannel "Hello" returns number of subscribers that received the message. - Verify subscriptions: PUBSUB CHANNELS lists active channels. PUBSUB NUMSUB mychannel returns subscriber count.

How it interacts with related technologies: - Real-time updates: Chat applications, live scoreboards, notifications. - Azure Functions: Use Redis Pub/Sub trigger (preview) to invoke functions on messages. - Comparison with Azure Service Bus: Redis Pub/Sub is simpler, lower latency, but lacks persistence, dead-letter queues, and advanced features. Use Service Bus for reliable messaging.

Persistence: Azure Cache for Redis offers RDB (snapshot) and AOF (append-only file) persistence. For cache patterns, persistence is optional; losing cache data is acceptable. For session caching, persistence is recommended to avoid mass logout on node failure.

Security: All Redis patterns should use TLS (port 6380) and access keys. Azure Cache for Redis supports private endpoints for VNet integration.

Enterprise Scenario 1: E-commerce Product Catalog A large online retailer uses Cache-Aside to serve product details. The product database is Azure SQL with millions of SKUs. Product data changes infrequently (price updates, descriptions). The application uses Redis Cache (Premium tier with 10 GB memory) to cache product data with a TTL of 1 hour. On cache miss, the application queries SQL and populates Redis. To handle inventory updates, the application publishes an event to invalidate the cache for the affected product. This pattern reduces database load by 90% and improves page load times from 200 ms to 5 ms. Common misconfiguration: setting TTL too long leads to stale pricing; too short defeats caching. The team uses allkeys-lru eviction policy to handle memory pressure.

Enterprise Scenario 2: Multi-Region Web Application with Session Persistence A SaaS provider runs a web app on Azure App Service across three regions. Users are load-balanced globally via Azure Traffic Manager. The app uses Redis Cache (Standard tier with geo-replication) for session caching. Each user's session data (authentication token, preferences) is stored in Redis with a 30-minute idle timeout. When a user's request hits a different region, the session data is still available because Redis is replicated. Without this, users would be logged out or lose state on region failover. The team monitors session count using DBSIZE and sets alerts when memory usage exceeds 80%. A common pitfall: forgetting to set SameSite cookie attributes, causing session loss in modern browsers.

Enterprise Scenario 3: Real-Time Notification System A financial trading platform uses Redis Pub/Sub to broadcast real-time stock price updates to thousands of web clients. Each client subscribes to specific stock channels (e.g., stock:AAPL). The backend publisher sends price updates every 100 ms. The web front-end uses WebSockets to relay messages from Redis to browsers. The system handles 10,000+ subscribers with sub-10 ms latency. A critical issue: if a subscriber's WebSocket connection drops, they miss updates until they reconnect. The team implemented a fallback: clients periodically poll a REST endpoint for missed updates. They also use PSUBSCRIBE for pattern matching (e.g., stock:*). Misconfiguration: publishing too many messages per second can overwhelm Redis single-threaded event loop, causing latency spikes. They throttle publishes to 50,000 msg/s per instance.