8.1 Azure Managed Redis: Caching, Expiration & Invalidation

Azure Managed Redis is Microsoft’s fully managed Redis service for Azure AI workloads. In AI-200 terms, you integrate it as a low-latency store for session state, retrieval results, feature values, and model-call artifacts—not as a replacement for your system of record. The exam expects you to implement data operations that keep AI paths fast while remaining correct when source data or prompts change.

Why Redis appears in AI solutions

Large language model (LLM) calls, vector searches against cold storage, and multi-step agent tool chains are expensive in latency and tokens. Azure Managed Redis sits next to those components so that hot keys—user session context, recently retrieved chunks, cached completions—are available in memory. Typical AI uses include:

• Session and conversation state — short-lived chat history or tool outputs keyed by conversation ID
• Feature and lookup caches — product, policy, or catalog facts that ground prompts
• Retrieval caches — results of expensive searches reused across similar requests
• Model-call caches — full responses or semantic matches so identical or near-identical prompts do not re-hit the model

Managed Redis gives you Redis protocol compatibility, Azure networking and identity integration, and operational concerns (patching, scaling, high availability) handled by the platform. Your application code still owns cache keys, lifetimes, and invalidation rules.

Core data operations: SET and GET

At the command level, the fundamental write is SET and the fundamental read is GET. SET stores a string (or binary) value under a key. GET returns the value if the key exists, or a null/nil result if it does not. In AI pipelines you almost always design an explicit key schema so every cache entry is addressable and deletable.

Example key patterns:

SET may optionally set a lifetime in the same call (for example SET with EX seconds), which is often preferred over a separate expire step so the write and TTL are atomic. GET after expiry behaves like a miss: the application must load from the primary store or recompute, then SET again.

For structured payloads, applications usually serialize JSON (or MessagePack) into the Redis string value. Keep values bounded; Redis is for hot, compact data. Large embeddings collections belong in dedicated vector indexes (covered in the next section) or in blob/search stores, with Redis holding pointers or small result sets.

Idempotent writes and overwrite semantics

SET replaces any existing value for that key. That overwrite behavior is what makes cache refresh simple: when you recompute a completion or reload a document snippet, SET the same key with the new payload. If you need “set only if absent” (first writer wins), Redis offers conditional forms such as SET NX; AI caches more often want unconditional SET so the newest computation wins.

Expiration: TTL and EXPIRE

Without expiration, cache keys live until deleted or until memory pressure eviction (depending on the maxmemory policy). AI caches almost always attach a time-to-live (TTL) so stale grounding data cannot linger indefinitely.

• EXPIRE key seconds — sets a TTL on an existing key
• TTL key — returns remaining seconds (−2 if missing, −1 if no expire)
• SET … EX seconds — creates the key already timed

Choose TTL by how fast the underlying truth changes and how costly a miss is:

When a key expires, the next GET is a miss. That miss is the signal to re-fetch from Azure AI Search, Cosmos DB, SQL, Blob Storage, or to call the model again. Do not treat expiry as invalidation of related keys: each key expires independently unless you design hierarchical deletes.

Cache-aside versus write-through

Two write policies dominate AI-200 scenarios.

Cache-aside (lazy loading)

1. Application GETs the key.
2. On hit, use the cached value.
3. On miss, load from the system of record (or call the model), then SET into Redis with a TTL.
4. Return the value to the caller.

Cache-aside is the default for read-heavy AI paths: RAG chunk lists, prompt templates, and response caches. The cache is never the authority; the database or model is. The downside is a stampede risk when many requests miss the same key simultaneously—mitigate with locks, single-flight patterns, or slightly staggered TTLs.

Write-through

1. Application writes to the primary store.
2. In the same logical operation, SET the new value into Redis (often with TTL).
3. Readers can GET without waiting for a miss to warm the cache.

Write-through fits when updates are infrequent and readers must see fresh data immediately after a write—for example, updating a policy document’s summary that agents always read from Redis. The cost is that every write pays Redis latency, and failed Redis writes must be handled so the primary and cache do not diverge silently.

For AI solutions, cache-aside is the pattern you will implement most often around LLM and retrieval calls; write-through appears when your app owns the mutation path for grounding content.

Invalidation on data change

TTL alone is not enough when a document, product record, or safety policy changes before the TTL ends. Invalidation means removing or overwriting cache entries so the next read cannot return the old value.

Practical invalidation tactics:

1. Delete by key — when document policy-441 updates, DEL doc:policy-441:meta, rag:… keys derived from it, and any llm:resp:… entries that embedded that content.
2. Versioned keys — include a content version or etag in the key (doc:policy-441:v12). Publishing v13 makes old keys unreachable; they expire harmlessly.
3. Namespace flush (careful) — delete by prefix/pattern only for bounded namespaces; never flush the entire cache in production as a routine fix.
4. Event-driven invalidation — on Cosmos DB change feed or Event Grid notifications, a worker deletes or refreshes related Redis keys.

Invalidation must cover derived AI artifacts. If you cached an LLM answer that quoted yesterday’s refund policy, deleting only the policy blob cache is insufficient—you must also invalidate response and semantic-cache entries that depended on that text.

Response caching and semantic caching for LLM calls

Response caching (exact match)

Build a deterministic hash of the normalized prompt (model name, temperature, system instructions, user message, and relevant tool context). Use that hash in a key such as llm:resp:{hash}. Flow:

1. GET llm:resp:{hash}.
2. Hit → return cached completion (no model call).
3. Miss → call Azure OpenAI / Foundry model → SET result with TTL → return.

Exact-match caching is safe when inputs are identical. It fails to help when users paraphrase (“What’s the return window?” vs “How many days to return?”).

Semantic caching

Semantic caching stores an embedding of the prompt (or of a canonical question) alongside the response. On a new request:

1. Embed the incoming prompt.
2. Run a similarity search against cached prompt vectors in Redis (vector index; next section).
3. If similarity exceeds a threshold, reuse the stored completion.
4. Otherwise call the model and insert a new vector + response pair with TTL.

Semantic caching amplifies savings but introduces wrong-answer risk if the threshold is too low or if grounding data changed. Pair it with short TTLs and aggressive invalidation when knowledge bases update.

Implementation checklist for AI-200

When a question asks you to implement Azure Managed Redis caching for an AI solution, map the scenario to operations:

• Use SET/GET for the data path and a clear key schema.
• Attach TTL/EXPIRE so entries leave memory predictably.
• Prefer cache-aside for model and retrieval results; use write-through when your service writes grounding data.
• On source change, invalidate keys and any LLM response/semantic entries derived from that source.
• Choose exact response caching for identical prompts and semantic caching only when similarity reuse is acceptable.

These operations—not the portal blades alone—are what the exam tests when it says “implement caching, expiration, and invalidation” with Azure Managed Redis.