Gain insights into Redis's capabilities as a database, cache, and message broker. Delve into commands, transactions, and clustering. Explore flexibility, security, and data structure support with Redis.

Redis.tar.gz

Redis is an open-source, in-memory data structure store used as a database, cache, and message broker. Unlike Memcached, it supports multiple data types, giving a lot of flexibility to the user. Redis is easy to configure and provides clustering support to store data in multiple servers.

In this course, you will learn about the various commands that you can use to store different types of data structures in Redis. Some of those commands include utility, insertion, and modification commands.

You will also become familiar with different aspects of Redis, such as transactions, security, partitioning, and clustering. In all, this is your go-to guide to Redis.

Complete Guide to Redis

## What is client-side caching

When the client requires data, they ask the Redis server to provide the data. Each back and forth from the server results in some bandwidth consumption, and it takes some time to get the result. It is possible to cache the result of the most frequently used keys on the client-side. This drastically improves the performance of the application, as it does not need to send requests to the database

## Challenges in client-side caching
The biggest challenge faced in caching the data on the client-side is how to invalidate the data. Suppose we have cached some data on the client-side, and it is changed on the server. The client will keep referring to the stale data present in its cache. There should be some mechanism to invalidate the data on the client's cache if it is changed on the server. There are two mechanisms to deal for this situation:
1. A TTL (time to live) can be set for each key that is cached on the client-side. After a certain time period has elapsed, the key will be automatically removed from the cache, and the client will need to refer to the database to get the value. Although this is a simple solution, it can only be used in those situations where the data is changed frequently. If the data is a few minutes old, then it does not matter. If the application is data sensitive and data is changing frequently, then this technique is not useful.
2. Another method is to use the PUB/SUB model of Redis to send **invalidate** messages to the client. Whenever a key is changed. the server will send invalidate messages to the clients. This will inform the clients that the key has been changed, and it should be deleted from the cache. The problem with this approach is that the server will need to send the message to all clients every time a key is changed, which can be very costly from the bandwidth point of view.

Redis 6 uses an alternate approach to solve these limitations. We will discuss how Redis handles client-side validation in the next section.

# What is client-side caching

When the client requires data, they ask the Redis server to provide the data. Each back and forth from the server results in some bandwidth consumption, and it takes some time to get the result. It is possible to cache the result of the most frequently used keys on the client-side. This drastically improves the performance of the application, as it does not need to send requests to the database

# Challenges in client-side caching
The biggest challenge faced in caching the data on the client-side is how to invalidate the data. Suppose we have cached some data on the client-side, and it is changed on the server. The client will keep referring to the stale data present in its cache. There should be some mechanism to invalidate the data on the client's cache if it is changed on the server. There are two mechanisms to deal for this situation:
1. A TTL (time to live) can be set for each key that is cached on the client-side. After a certain time period has elapsed, the key will be automatically removed from the cache, and the client will need to refer to the database to get the value. Although this is a simple solution, it can only be used in those situations where the data is changed frequently. If the data is a few minutes old, then it does not matter. If the application is data sensitive and data is changing frequently, then this technique is not useful.
2. Another method is to use the PUB/SUB model of Redis to send **invalidate** messages to the client. Whenever a key is changed. the server will send invalidate messages to the clients. This will inform the clients that the key has been changed, and it should be deleted from the cache. The problem with this approach is that the server will need to send the message to all clients every time a key is changed, which can be very costly from the bandwidth point of view.

Redis 6 uses an alternate approach to solve these limitations. We will discuss how Redis handles client-side validation in the next section.

Let’s discuss the ways to implement client-side caching in Redis.

Let's Begin

Redis Commands

Redis Advanced Concepts

Redis Cluster

Appendix

Redis: Client side caching

What is client-side caching

Challenges in client-side caching