performance-observabilityAnswer last reviewed July 2026

Let's say you're adding a cache in front of a hot read path. What are the decisions that actually determine whether it helps or blows up on you?

A strong answer picks the cache layer by its consistency and invalidation behavior, and knows a stampede can make a cache hurt more than it helps

What an AI-prepared candidate might say

A cache makes sense when reads happen a lot, the data's expensive to fetch, and it doesn't change too often. The main decision is where to put it. An in-process cache is fastest because it's just memory in the same process, but each instance keeps its own copy, so instances can disagree. Something shared like Redis stays consistent across instances and holds more, but you pay a network hop. You set a TTL so entries expire, and you still need an invalidation plan for when data changes. The known problem is a cache stampede, where a popular item expires and a bunch of requests all recompute it at once and overload the backend. You prevent that with a lock so only one request recomputes, or by refreshing before expiry. And you watch the hit rate to confirm it's doing its job. Really it depends on your consistency and performance needs.

Senior
Locked

The three axes that actually matter, placement, consistency, and invalidation, plus why an in-process cache drifts per instance and how a hot key's expiry turns into a stampede.

Unlock the depth
Staff
Locked

How you stop stampedes with a lock or early recompute, pick a placement that fits your consistency needs, and why hit rate and origin load only make sense measured together.

Unlock the depth
Follow-up chain
Let's say you're adding a cache in front of a hot read path. What are the decisions that actually determine whether it helps or blows up on you? | NodeBook