Recommend a Caching Solution for Applications — Lesson

Caching is an architecture decision about where repeated work should stop. A database query, API call, rendered page, identity lookup, or image transformation may be correct and still be too slow or expensive to repeat for every request. A good cache absorbs repetition while preserving the application's correctness, security, and recovery behavior. A poor cache hides stale data, amplifies outages, or becomes an accidental system of record.

This lesson uses the current Azure service model: Azure Managed Redis for regional in-memory application caching and Azure Front Door Standard or Premium for global edge caching. It is aligned to the AZ-305 objective “Recommend a caching solution for applications.” The attached course books remain the conceptual baseline; current Microsoft Learn documentation controls changing product names, tiers, topology, and availability.

Why this matters

Caching changes the shape of a workload. It can lower database read volume, shorten response times, protect an origin during bursts, and reduce cross-region traffic. Those benefits are multiplicative: a cache hit avoids not only the data read but also the CPU, connection, serialization, and network work behind that read.

The risks are equally important. Cached authorization decisions can outlive a revocation. Session state can disappear during failover. A shared cache can allow one noisy workload to evict another workload's keys. An edge cache can expose personalized content if cache keys ignore identity or request variation. AZ-305 scenarios therefore test more than product recognition. You must identify the cacheable data, staleness budget, failure behavior, security boundary, and operating owner.

A strong architecture answer sounds like this: “Use Azure Managed Redis with high availability for shared session state because all app instances need the same low-latency data. Use cache-aside with explicit invalidation and a bounded TTL. Treat the database as the source of truth, and let requests fall back to it during a cache outage. Reject process-local memory because it is neither shared nor durable across app-instance replacement.”

Prerequisites

Before continuing, verify that you can explain:

• the difference between a source of truth and a derived copy;
• the read and write paths of cache-aside;
• time to live (TTL), eviction, and invalidation;
• the difference between regional application caching and global HTTP edge caching;
• why idempotency and retry behavior matter during cache failure;
• how private endpoints and Microsoft Entra authentication change the trust boundary.

Learning objectives

By the end of this lesson, you should be able to:

1. classify data by reuse, staleness tolerance, sensitivity, and working-set size;
2. choose between process-local, Azure Managed Redis, database-native, and Front Door caching;
3. choose an Azure Managed Redis tier from memory-to-compute needs rather than retired product labels;
4. decide whether to enable high availability, persistence, active geo-replication, and a clustering policy;
5. design cache-aside and invalidation paths with safe fallback behavior;
6. design Front Door cache keys, TTLs, query-string handling, and purge behavior;
7. identify anti-patterns that turn a performance layer into a correctness or security incident.

Building blocks

Cache-aside means the application checks the cache first. On a miss, it reads the source of truth, returns the value, and stores a derived copy with a TTL. On a write, the application changes the source of truth and invalidates or refreshes the cached value. Cache-aside is the safest default because the origin remains authoritative.

TTL is a maximum lifetime for a cached value. It bounds staleness and provides a recovery path when invalidation misses an edge case. TTL is not a replacement for invalidation when rapid consistency matters; it is the safety net.

Eviction is removal caused by memory pressure. Choose a policy that matches the data model. A cache of disposable values usually benefits from a least-recently-used or least-frequently-used policy. A system using Redis as a durable store may instead reject writes when memory is full—but then it is no longer behaving like a disposable cache.

Azure Managed Redis is Microsoft's managed, Redis Enterprise–based in-memory data service. It supports cache-aside, session state, leaderboards, messaging, deduplication, and other low-latency patterns. It exposes four current tier families: Memory Optimized, Balanced, Compute Optimized, and Flash Optimized.

High availability deploys primary and replica shards across at least two nodes. In regions with availability-zone support, the service distributes nodes across zones by default. Disable high availability only for disposable development or test environments that can tolerate data loss and downtime.

Data persistence stores a recovery copy on disk. It is different from Flash Optimized operation. Persistence improves recovery after an unexpected outage; Flash Optimized uses NVMe as part of normal data placement to make large, read-heavy working sets more economical.

Active geo-replication joins compatible Azure Managed Redis instances across regions. Use it only when the workload genuinely needs local regional access and can accept the replication and conflict model. A cache should rarely be the sole owner of irreplaceable business data.

Azure Front Door caching stores cacheable HTTP responses at edge locations. It is appropriate for static assets and carefully selected public responses. Front Door also provides global Layer 7 routing, TLS termination, health-aware origin selection, and—on the appropriate tier—WAF and private connectivity to origins.

The first decision: what is being cached?

Start with the object, not the service.

The staleness budget drives the design. Product catalog text may tolerate several minutes. Inventory availability may tolerate seconds. A revoked entitlement may tolerate almost no delay. Write the budget before writing the cache key.

Choosing an Azure Managed Redis tier

The current tiers describe the ratio of memory, compute, and flash, not a simple ladder from development to production.

Enable high availability independently of tier selection for production. Then decide whether the application requires persistence, geo-replication, modules such as search or JSON, and a particular client topology. Avoid selecting a tier from a memorized numeric limit: current region, SKU, connection, and preview status must be verified during implementation.

Cluster policy

Azure Managed Redis offers OSS, Enterprise, and non-clustered policies.

• OSS clustering is the normal starting point when the client supports the Redis Cluster API. Clients connect to shards and can achieve strong throughput and low latency.
• Enterprise clustering presents a simpler endpoint and routes commands through a proxy. It helps compatibility and is required for some module scenarios, but the proxy can become a throughput consideration.
• Non-clustered is a compatibility choice for smaller workloads that depend on cross-slot or non-sharded command behavior. Treat it as an exception justified by client behavior, not a default.

Multi-key commands deserve explicit testing. In a clustered topology, related keys should use a hash-tag strategy when they must occupy the same slot. A design that relies on arbitrary cross-key transactions can fail with cross-slot errors after migration.

Cache-aside, invalidation, and stampede control

The write path is at least as important as the read path. Update the source first, then delete or replace the cached copy. If the cache operation fails, the next read must still be able to recover from the origin. For high-write objects, event-driven invalidation can distribute changes to multiple regions, but it creates its own delivery and ordering contract.

A cache stampede occurs when many requests miss the same hot key and all query the origin. Prevent it with one or more of these controls:

• single-flight locking so only one request refreshes a key;
• randomized TTL jitter so related keys do not expire at the same instant;
• stale-while-revalidate behavior for content that can briefly serve an older copy;
• prewarming for predictable events;
• origin rate limiting and circuit breaking.

Negative caching can protect an origin from repeated lookups for missing data. Give “not found” entries a short TTL so a newly created item becomes visible promptly.

Failure and recovery design

Ask what the application does when Redis is slow, unavailable, empty, or partially replicated.

1. Timeout quickly. Cache calls should not consume the full request budget.
2. Fall back deliberately. A read-through fallback to the database is appropriate only if the database can absorb the surge.
3. Limit concurrency. Circuit breakers and bulkheads prevent thousands of fallback reads from becoming a database outage.
4. Treat cache loss as expected. Rebuild derived data from the source of truth.
5. Test failover. Verify client reconnect behavior, DNS handling, retry limits, and duplicate work.
6. Monitor effectiveness. Track hits, misses, evictions, latency, memory pressure, connections, server load, errors, and origin fallback volume.

Persistence is not permission to store irreplaceable state only in Redis. It is a recovery aid. If a workflow requires a durable, ordered, auditable business event, use a database or messaging service as the authoritative system and derive cache entries from it.

Security and network design

Use a private endpoint when the workload requires private network reachability. Restrict public access, configure name resolution, and validate failover from every application subnet. Prefer Microsoft Entra authentication where supported so the application does not carry a long-lived access key. Use managed identities and least-privilege data access.

Do not cache secrets merely to avoid Key Vault calls unless the security design explicitly permits an in-process bounded cache. Secret rotation and revocation are more important than shaving a few milliseconds. Do not put tenant-identifying or sensitive values into predictable keys if operators or diagnostics can expose those keys. Encrypt transport, control administration, and route service diagnostics to the approved monitoring boundary.

Edge caching with Azure Front Door

Front Door caching operates on HTTP responses and request variation. Define exactly what forms the cache key: path, selected query parameters, headers, device or locale variation, and—usually by exclusion—identity. Never cache a personalized response under a shared public key.

Respect origin cache directives where practical. Use versioned asset URLs for long-lived static files, because a new URL is safer than relying on emergency purge. Use shorter TTLs for mutable public content. Define a purge runbook for incorrect or sensitive content. Compression reduces transfer size but does not correct a bad cache key.

Worked examples

Example 1: shared sessions

An App Service deployment scales across many instances. Sessions currently live in process memory, so users lose carts during scale-out or instance replacement. Use Azure Managed Redis as a shared session store, begin with the Balanced tier, enable high availability, and use a private endpoint. Choose a TTL that matches session policy. The application should survive a brief cache failure by asking the user to reauthenticate or rebuild noncritical state; it must not silently accept an invalid session.

Reject process-local memory because it is not shared. Reject a relational database as the first choice because the workload is latency-sensitive, high-volume, and disposable—unless audit or transaction requirements make the session authoritative.

Example 2: hot product records

A product page repeatedly reads the same catalog entities. Use cache-aside in Azure Managed Redis. The database remains authoritative. On catalog update, commit the database transaction, publish an invalidation event, and delete the affected key. Add TTL jitter and single-flight refresh. Measure hit rate and origin fallback rather than assuming the cache helps.

Reject write-behind because losing queued catalog changes would violate the authoritative-data contract. Reject an edge-only cache if the same entities also serve internal APIs with regional, non-HTTP access patterns.

Example 3: global public assets

A public site serves hashed JavaScript bundles and images from Blob Storage. Use Front Door caching with long TTLs on versioned paths, compression, an origin group, and health probes. A deployment publishes new hashes rather than overwriting old assets. The HTML shell can use a shorter TTL so it begins referencing the new assets promptly.

Reject Azure Managed Redis for this job because the content is HTTP-delivered and benefits from global edge proximity. Redis would add a regional application hop and would not reduce client-to-region latency.

Example 4: large read-heavy working set

An analytics application has a very large Redis-compatible index, but most reads target a smaller hot subset. Evaluate Flash Optimized because it can place cold values on NVMe while retaining keys and hot values in memory. Benchmark with realistic occupancy; a nearly empty test can hide the latency effect of flash. If the full set is uniformly hot or write-heavy, compare Memory Optimized, Balanced, and Compute Optimized with measured command rate and memory demand.

Common mistakes

• Choosing a tier before measuring the working set. Size from serialized value size, key overhead, replication buffer, growth, and connection behavior.
• Assuming high availability is automatic in every configuration. Make the production HA decision explicit and test it.
• Using one cache for unrelated workloads. Shared memory creates eviction coupling and a shared failure domain.
• Caching without a TTL. One missed invalidation can create indefinite staleness.
• Using the cache as the only system of record. Recovery and audit become fragile.
• Ignoring cluster behavior. Multi-key commands may fail when keys land in different slots.
• Caching private responses at the edge. A bad key can leak one user's data to another.
• Measuring only latency. Track correctness, fallback pressure, evictions, error rate, and origin capacity.

Practice exercises

1. A service has a 40% hit rate after doubling cache capacity. What do you investigate? Check key reuse, TTL length, population after misses, working-set churn, and whether the requests are actually cacheable before buying more capacity.
2. A cache outage sends all requests to SQL and SQL fails. What design was missing? Fast cache timeouts, a circuit breaker, concurrency limits, origin capacity planning, and a degraded response path.
3. A multilingual page varies by Accept-Language but the edge key uses only the path. What can happen? One locale can be served to users requesting another. Add safe variation or use locale-specific paths.
4. A client uses multi-key transactions after moving to an OSS clustered policy. What must be tested? Hash-slot placement and client Cluster API behavior; related keys may need a shared hash tag.
5. A product owner asks for “zero stale data” and “aggressive caching.” What should the architect do? Quantify the actual staleness budget, identify invalidation events, and explain that zero staleness may require bypassing the cache for that decision.

Summary and decision map

The exam decision is not “Which cache is fastest?” It is “Which layer can safely absorb this repeated work, under this staleness, failure, security, and operating contract?” Use Azure Managed Redis for shared regional application data; use Front Door for safe global HTTP caching; keep the source of truth outside the cache; and make invalidation and failure behavior part of the recommendation.

Source and freshness

Grounded in both attached AZ-305 corpus documents and reviewed against current Microsoft Learn documentation for Azure Managed Redis overview, architecture, persistence, and Azure Front Door. Reviewed 2026-08-02. Verify current region, tier, feature, and preview availability during implementation.