I usually start by profiling the real traffic – what queries actually run, how often, and how much data they touch. If a few SELECTs pull huge joins and you can afford a write‑heavy index, a well‑tuned composite index can shave milliseconds off the response, but it also means more maintenance cost on inserts and updates. Caching, on the other hand, gives you instant reads and scales out, but you’re betting on cache hits and dealing with consistency issues. In practice I’ll add a narrow index for a hot path, then layer a read‑through cache for the bulk of the traffic. If the cache hit ratio climbs above, say, 90%, I’ll consider dropping the heavier index. The key is keeping the system simple and observable; too many moving parts just create silent failures.

Good point—those eviction stats are the silent alarm. I’ll make sure the monitoring alerts pop when hit rates dip, and I’ll schedule a quick sanity check during the next ops window. Keeps everything lean and avoids the “index‑caching paradox.”