In my experience microservice architectures end up very network traffic heavy. By virtue of having N instances, multiple instances can and will request the same

In my experience microservice architectures end up very network traffic heavy. By virtue of having N instances, multiple instances can and will request the same data over and over. User A requests page 1 of results for "hello world" and goes to instance X, user B requests page 1 of results for "hello world" and goes to instance Y, etc. Given that the stability and availability of your central data store in your model is likely more important than the N instances talking to it, caching data on those instances is definitely beneficial, rather than asking it for the same data over and over. You need not reserve that much additional RAM, modern infrastructures end up with unused RAM anyways, by virtue of them being optmised for CPU usage of stateless microservices. Why not put it to use? A smart cache eviction strategy can help optimise what gets held in RAM and what doesn't. A Redis client working in tandem with the Redis server can help with that and stop you needing to write a bunch of code to do this.