In-memory caches

Keeping hot data in memory, in the process or in Redis, avoids repeating expensive queries and calls. The hard part is invalidation: deciding when a cached value is stale and what to do when it is missing.

What a session covers

The tutor works through these with you, in conversation and code. A session ends when you have shown them, not when a video does.

Explain what a cache saves and why invalidation is the hard part
Cache a hot query with a TTL in memory or Redis
Spot the unbounded cache that grows until the process dies

In practice

A few lines that show In-memory caches doing its job.

JavaScript

const cache = new Map();   // key -> { value, expiresAt }

async function cached(key, ttlMs, load) {
  const hit = cache.get(key);
  if (hit && hit.expiresAt > Date.now()) return hit.value;
  const value = await load();
  cache.set(key, { value, expiresAt: Date.now() + ttlMs });
  return value;
}

const rates = await cached("fx:USD", 60_000, () => fetchRates("USD"));

The common mistake

Watch for

An unbounded in-process cache that grows until the process runs out of memory. Give it a maximum size and an eviction policy, or use Redis with a TTL.

What to know first

Your roadmap puts these before In-memory caches, unless you already know them.

Promises and async/await

How it stays learned

Once a session shows you understand In-memory caches, it comes back for review. Each review takes a minute and tells the memory model how well you still know it.

Day 3First recall, while it is fresh
Day 7Second, a week on
Day 18Last, when it has settled

Previous in the module← HTTP caching

Next in the moduleProfiling →