1. Caching Patterns
- Cache-Aside — App manages cache explicitly. Best for read-heavy workloads. Risk: stale data until TTL expires.
- Write-Through — App writes to cache and DB simultaneously. Guarantees consistency but adds write latency.
- Write-Behind (Write-Back) — App writes to cache; cache asynchronously flushes to DB. Lowest write latency but risk of data loss on failure.
2. Azure Cache for Redis Tiers
3. Clustering & Geo-Replication
- Clustering — Splits data across shards (hash slots 0–16383). Each shard is a primary + replica pair. Increases throughput linearly with shard count.
- Passive Geo-Replication (Premium) — Links two caches across regions; secondary is read-only. Manual failover required.
- Active Geo-Replication (Enterprise) — Multi-write across regions with conflict-free replicated data types (CRDTs). Automatic conflict resolution, near-zero RPO.
Design tip: Use active geo-replication for globally distributed apps needing local read/write latency in each region.
4. Persistence (RDB / AOF)
- RDB (Snapshot) — Point-in-time snapshots at configured intervals (e.g., every 15 min). Lower performance impact; larger potential data loss window.
- AOF (Append-Only File) — Logs every write operation. Near-zero data loss; higher storage I/O. Options: fsync every second or every write.
- Both — Can enable RDB + AOF together for fast restarts (RDB) with minimal loss (AOF).
Persistence writes to Azure-managed storage. For Premium tier, stored in geo-redundant storage by default.
5. Connection Best Practices
- Connection Pooling — Reuse connections (e.g., StackExchange.Redis
ConnectionMultiplexeris thread-safe — create once, share globally). - Retry with Backoff — Use exponential backoff for transient failures. Configure
connectRetryandretryTimeout. - Avoid per-request connections — Opening/closing connections is expensive (~20ms). Singleton pattern is essential.
- Set reasonable timeouts —
syncTimeout=5000msfor most workloads; increase for large payloads. - Use SSL/TLS — Always enable (port 6380). Disable non-SSL port (6379) in production.
- Monitor — Track
connected_clients,cache_hits/misses,server_load,memory_usagevia Azure Monitor.
6. When Caching Helps vs Doesn't
| ✅ Cache Helps | ❌ Cache Doesn't Help |
|---|---|
| Read-heavy, low-write workloads | Write-heavy with constant invalidation |
| Expensive queries (joins, aggregations) | Data changes every request (real-time pricing) |
| Session state across stateless web servers | Large objects that exceed memory budget |
| Reference data (country lists, configs) | Rarely accessed data (cold storage) |
| Rate limiting & leaderboards | Strong consistency required on every read |
🌍 Real-World Scenario
E-Commerce: Session Store + Product Catalog Cache
An online retailer uses Azure Cache for Redis (Standard tier) as a distributed session store for 50 stateless App Service instances — users maintain cart state across any server. A second Premium-tier clustered cache (4 shards) stores product catalog data using cache-aside pattern with 10-minute TTL. During flash sales, the cache absorbs 95% of reads, keeping SQL Database DTU consumption flat. Write-through updates prices on admin changes. Active geo-replication (Enterprise) keeps the US and EU storefronts under 5ms local read latency.
📝 Exam Tip
When a question requires multi-region active-active caching with writes in both regions, the answer is Enterprise tier with active geo-replication. Premium supports only passive (read-only secondary). For persistence, remember: RDB = snapshots (some data loss acceptable), AOF = near-zero data loss. If the question says "no data loss on restart," choose AOF.
🧪 Knowledge Check
Q1: In the cache-aside pattern, what happens on a cache miss?
Q2: Which tier supports active geo-replication with writes in multiple regions?
Q3: Which persistence option provides near-zero data loss?
Q4: What is the recommended connection pattern for StackExchange.Redis?