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
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.