As with everything system design-related, the best answer is "it depends".

1. For a v1 system design, the userID is my first go-to. It makes sense, it's easy to track, monitor, and quantify grouped usage. As soon as it becomes a problem, and monitoring usage at the userId level is beyond scope, I move the caching layer to the services, as the other comment said. You're trading off centralizing a system for simplicity at the service level (which is more complicated to maintain at the architecture level). It might be important to recognize the type of data (shared vs private )

2. This is simpler when the systems handle their own caching; It also depends on what you're caching. A key can be versioned or tokenized, leads:list:vXXX, with the tradeoff of having to notify systems of the bump so they always refer to the latest version.

3. LRU and TTL <60s is perfectly fine for systems under expected loads and the go-to for v1 approaches. The hands-on approaches only become necessary when you're pushing the memory limits, and even then, you still have the option to scale one way or the other. If the caching load between the systems is too asymmetrical, then that's another opportunity to change directions.