4 ms·

> "I really believe that in the future of Redis “client side caching” will be a big thing. It’s the logical step in every scalable system." How is this a logic

> "I really believe that in the future of Redis “client side caching” will be a big thing. It’s the logical step in every scalable system." How is this a logical step in the context of micro services ? I feel there is a trade off. If I have to scale a service to N instances where each of them cache the same type of data. Potentially, I'm duplicating that data N times. Which means I need to reserve that much additional RAM per instance. I can avoid this by storing the data centrally in a very fast cache aka Redis. On the other hand even the fastest standalone cache will be much slower then accessing data in process memory.

legohead 8y ago
depends on what your application demands. I've worked on applications where response times more than 3ms could cost the company thousands of dollars. And I've worked on applications where 30ms and nobody would even notice...
- antirez 8y ago
  I may add that, 99% of the very big Redis users out there do some form of client side caching... at scale is basically something common for many years now.
amdelamar 8y ago
Yes in-memory is the fastest, but I think its useful when comparing SQL queries (slow) to querying Redis (faster) for cache data, especially for distributed systems.
nathankunicki 8y ago
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.
illumin8 8y ago
> If I have to scale a service to N instances where each of them cache the same type of data. Actually, they don't. If you're scaling a multi-user system to millions of users across hundreds/thousands of instances of your micro-service, they're likely to cache different data because different user sessions will be handled by each instance of your app. So, local caching in each micro-service is valuable. You just need to set an upper limit on how much memory to consume.

legohead 8y ago

depends on what your application demands. I've worked on applications where response times more than 3ms could cost the company thousands of dollars. And I've worked on applications where 30ms and nobody would even notice...

antirez 8y ago
I may add that, 99% of the very big Redis users out there do some form of client side caching... at scale is basically something common for many years now.

amdelamar 8y ago

Yes in-memory is the fastest, but I think its useful when comparing SQL queries (slow) to querying Redis (faster) for cache data, especially for distributed systems.

nathankunicki 8y ago

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.

illumin8 8y ago

> If I have to scale a service to N instances where each of them cache the same type of data. Actually, they don't. If you're scaling a multi-user system to millions of users across hundreds/thousands of instances of your micro-service, they're likely to cache different data because different user sessions will be handled by each instance of your app. So, local caching in each micro-service is valuable. You just need to set an upper limit on how much memory to consume.