Azure Managed Redis is the current managed Redis offering for low-latency in-memory data patterns on Azure. A cache reduces repeated work; it is not automatically a durable system of record. Design keys, expiration, invalidation, memory limits, failure behavior, security, and stampede control before introducing it.
Important: Azure Cache for Redis has retirement timelines for its SKUs. New designs should review Azure Managed Redis and the current Microsoft migration guidance instead of starting from a legacy tutorial.
Do not use a cache as the only copy of irreplaceable business data unless the selected persistence and recovery design explicitly supports that risk.
Cache-aside: the app reads cache, loads the database on miss, then stores with TTL. It is simple, but concurrent misses can stampede the database.
Write-through/write-behind: updates flow through a cache layer. These add consistency and failure complexity.
Versioned keys: include a version in the key so invalidation becomes switching versions rather than deleting every entry.
Review the current Azure Managed Redis feature, region, SKU, and API-version matrix before either method. Keep authentication private and estimate the always-on capacity cost.
Ways to build
Choose the Azure tool you want to use. The underlying resource stays the same.
Search Azure Managed Redis → Create. Choose region, balanced or memory-optimized tier/capacity, clustering, high availability, persistence only when required, and private networking. Create the cache, assign its consuming managed identity the supported data role, test from the connected VNet, then disable access-key authentication only after every client uses Entra authentication.
Use Entra authentication and managed identity where supported. Disable access-key authentication after all clients support Entra. Use private endpoints/DNS for private workloads, require TLS, and never expose the service broadly to the internet.
CLI, Bicep, PowerShell, and Terraform support evolves with a newer service. Use the current Microsoft.Cache/redisEnterprise or documented Azure Managed Redis resource type/API, and verify provider support before standardizing a module. Do not copy an azurerm_redis_cache legacy example into a new production design without checking retirement guidance.
Use a readable namespace such as:
Do not place secrets or raw personal data in key names because keys appear in diagnostics and operational tools. Add jitter to TTLs to prevent thousands of keys expiring at the same second. Bound value size and serialization format.
Choose explicitly:
Set short connection timeouts, bounded retries with jitter, circuit breakers, and bulkheads. An unbounded fallback can turn a cache incident into a database incident.
Monitor memory use, fragmentation, evictions, CPU, server load, connections, operations, latency, bandwidth, errors, replication health, and persistence status. Alert before max memory and connection limits. Sample hot keys carefully because inspection can affect production.
Inventory SKU, data size, modules, clustering, persistence, network, authentication, client versions, and downtime tolerance. Test compatibility, provision the target, configure private access and Entra identity, copy/warm data as appropriate, dual-read only with a designed consistency plan, switch traffic, monitor, and retire the legacy instance before its applicable deadline.
Use application memory for single-instance disposable caching, Front Door/CDN for HTTP content, Cosmos DB for durable globally distributed data, Service Bus for durable brokered work, and database-native features for authoritative state. The lowest-latency product is not automatically the simplest system.