Redis and Memcached Caching

The production problem this solves

A developer can know the syntax behind Redis and Memcached Caching and still make the wrong production decision. This lesson closes that gap. This lesson defines an application trust boundary, where an explicit contract is safer than framework convention or an undocumented assumption.

Here, that decision supports a specific checkpoint: Build an enrollment flow that writes once, caches safely and sends a retryable confirmation without losing or duplicating work. A reviewable result should include a repeatable request, automated test, query result and failure response rather than a claim that the feature simply works.

A practical model for redis and memcached caching

Cache a bounded public response with explicit keys, expiry and invalidation instead of treating cache as invisible speed. The useful unit of understanding is the boundary: who owns the decision, which input crosses it, what result is visible and how a failure is reported.

• Cache-aside: Decide what belongs in code, configuration, data or documentation and explain why.
• TTL: Name its input, observable result and most likely failure in this lesson.
• Invalidation: Locate this responsibility in CourseFlow and defend the boundary you chose.
• Cache Stampede: Implement one behavior that another learner can reproduce without reading your mind.

Engineering decisions for Redis and Memcached Caching

These are the details that separate a working demonstration from a maintainable production decision.

• Redis offers data structures and persistence options; Memcached stays focused on volatile key-value caching.
• Never use a shared cache key that omits tenant, authorization or representation differences.
• Protect the origin from a stampede with request coalescing, jitter or stale-while-revalidate when traffic justifies it.

Explain each moving part

Before running the sample, predict how changing TTL will alter the result. The prediction is part of the exercise.

const key = `course:${courseId}:summary:v2`;
let summary = await redis.get(key);

if (summary === null) {
  const fresh = await courses.loadPublicSummary(courseId);
  summary = JSON.stringify(fresh);
  await redis.set(key, summary, { EX: 60, NX: true });
}

return JSON.parse(summary);

Trace the implementation boundary

1. 1
   Cache-aside

   Run the focused example and save the output, trace, query or screenshot that confirms the result.

2. 2
   TTL

   Break one assumption on purpose, make recovery clear and record the trade-off you accepted.

3. 3
   Invalidation

   Name the caller and the owner of this behavior before changing the implementation.

4. 4
   Cache Stampede

   Compare expected and actual output before editing; the difference tells you where to investigate.

Check your reasoning

What to carry into the next lesson

• Cache a bounded public response with explicit keys, expiry and invalidation instead of treating cache as invisible speed.
• Keep cache-aside visible at the boundary where it can be tested.
• Use evidence from TTL before widening the implementation.

References and related reading

• Redis documentation
• Memcached documentation