Write-Through Caching with Azure Managed Redis and Azure SQL
Guidance dated June 30, 2026
Problem
Read-heavy applications need low-latency access and fresh values after application-controlled writes while Azure SQL Database remains the durable source of truth.
My contribution
I authored the Microsoft Learn / Azure Architecture Center guidance, including write-path coordination, partial-failure handling, cache repair, and operational tradeoffs.
Key decisions
- Commit the authoritative SQL transaction before updating Redis. Only treat the coordinated write as complete after the corresponding cache update succeeds; a SQL commit and a cache update are not one atomic transaction.
- Use a durable SQL outbox and idempotent repair function when SQL commits but Redis cannot be updated. Repair makes recovery explicit rather than claiming the cache is always consistent.
- Choose write-through for read-heavy paths requiring fresh reads after controlled writes. Prefer direct SQL reads, cache-aside, or asynchronous refresh when their simpler consistency and cost tradeoffs fit better.
Evidence
Microsoft Learn / Azure Architecture Center guidance dated June 30, 2026. The published design covers reliability, security, cost, observability, TTLs, private connectivity, and cache-key design. It is architectural guidance, not a claim of measured customer production outcomes.
Technical detail
I authored a Microsoft Learn reference architecture for implementing write-through caching with Azure Managed Redis and Azure SQL Database.
The architecture addresses a common problem in high-traffic applications: SQL Database needs to remain the authoritative system of record, but repeated reads can increase latency and database load as traffic grows. Azure Managed Redis provides the low-latency distributed cache layer, while Azure Functions coordinates the write-through path so application-controlled writes update SQL first, then update the corresponding Redis cache entry before the operation is treated as complete.
The design uses Azure App Service for the application tier, Azure Functions for the write-through and repair logic, Azure SQL Database as the system of record, Azure Managed Redis as the distributed cache, Azure Private Link for private connectivity, and Azure Monitor for observability across the full request path.
Challenges & Solutions
Designing a caching pattern that improves read latency without pretending Redis is the authoritative data store.
Preserving read-after-write behavior for application-controlled writes by coordinating SQL commits and Redis cache updates through a single write-through function.
Handling partial failure cases where SQL commits successfully but Redis cannot be updated immediately.
Using a durable SQL outbox table and repair function so failed cache updates can be retried idempotently after the authoritative write succeeds.
Defining clear guidance for when write-through caching is appropriate versus simpler patterns like cache-aside or asynchronous refresh.
Mapping the architecture to Azure Well-Architected pillars, including reliability, security, cost optimization, operational excellence, and performance efficiency.
Outcomes
Published a production-minded Azure Architecture Center pattern for write-through caching with Azure Managed Redis and Azure SQL Database.
Provided implementation guidance for teams that need low-latency reads while keeping SQL Database as the durable source of truth.
Clarified failure handling, idempotency, TTL strategy, cache key design, private networking, observability, and operational guardrails for real-world Azure workloads.
Created reusable field guidance that helps customers, Microsoft teams, and Redis teams reason about caching consistency, write-path ownership, and Redis adoption patterns on Azure.
Tech Stack
Explore
Philip Laussermair
Global Azure Managed Redis Lead Architect at Redis.