In-process cache versus something shared like Redis, how do you actually make that call when you're running a fleet?
Strong answers weigh hit-rate dilution, invalidation reach, and GC cost before placing a cache, then defend a layered design with staleness bounds.
An in-process cache, so a Map or an LRU living inside the instance, is the fastest thing you can do. No network hop, no serialization, it's just a heap read. The downsides are duplication, since every instance caches its own copy, inconsistency between instances, and you lose it all on every restart. A shared cache like Redis gives all the instances one view, survives deploys, and each key gets cached once. But you pay a network round trip and serialization on every hit, plus it's a new dependency you have to operate. The pattern I've seen is layering them, a small short-TTL in-process cache in front of Redis in front of the origin, so hot keys are nearly free and the shared layer keeps the fleet roughly consistent. Which way you lean depends on how hot the data is, how much staleness you can tolerate, and how expensive the origin fetches are.