# Client side caching in Redis 6

DevFeed: [Client side caching in Redis 6](<https://devfeed.tech/articles/client-side-caching-in-redis-6-20621.md>)

Original publisher: [Read original article](<http://antirez.com/news/130>)

Published: 2019-07-04T17:10:34Z

Content type: article

Language: en

Sources: [Antirez](<https://devfeed.tech/sources/antirez.md>)

Topics: [Caching](<https://devfeed.tech/topics/caching.md>), [Redis](<https://devfeed.tech/topics/redis.md>), [Protocol (disambiguation)](<https://devfeed.tech/topics/protocol.md>), [client](<https://devfeed.tech/topics/client.md>)

Tags: [caching](<https://devfeed.tech/tags/caching.md>), [protocol](<https://devfeed.tech/tags/protocol.md>), [redis](<https://devfeed.tech/tags/redis.md>), [release](<https://devfeed.tech/tags/release.md>)

## AI overview

The article discusses client-side caching as a major motivation for Redis 6 and explains how RESP3 was intended to support more semantic replies and new features. It also notes that the described client-side implementation changed significantly in the final Redis 6 implementation.

## Source excerpt

[Note: this post no longer describes the client side implementation in the final implementation of Redis 6, that changed significantly, see https://redis.io/topics/client-side-caching] The New York Redis day was over, I get up at the hotel at 5:30, still pretty in sync with the Italian time zone and immediately went walking on the streets of Manhattan, completely in love with the landscape and the wonderful feeling of being just a number among millions of other numbers. Yet I was thinking at the Redis 6 release with the feeling that, what was probably the most important feature at all, the new version of the Redis protocol (RESP3), was going to have a very slow adoption curve, and for good reasons: wise people avoid switching tools without very good reasons. After all why I wanted to improve the protocol so badly? For two reasons mainly, to provide clients with more semantical replies, and in order to open to new features that were hard to implement with the old protocol; one feature in particular was the most important to me: client side caching. Rewind back to about one year ago. I arrived at Redis Conf 2018, in San Francisco, with the firm idea that client side caching was the most important thing in the future of Redis. If we need fast stores and fast caches, then we need to store a subset of the information inside the client. It is a natural extension of the idea of serving data with small delays and at a big scale. Actually almost every very large company already does it, because it is the only way to survive to the load eventually. Yet Redis had no way to assist the client in such process. A fortunate coincidence wanted Ben Malec having a talk at Redis Conf exactly about client side caching [1], just using the tools that Redis provides and a number of very clever ideas. [1] https://www.youtube.com/watch?v=kliQLwSikO4 The approach taken by Ben really opened my imagination. There were two key ideas Ben used in order to make his design work. The first was to use