Redis Overview: Why We Use It and How It Works (With Example)

We could jump straight into the example, but it’s better to first understand what Redis actually is. Without that foundation, the example won’t make as much sense.

What is Redis?

Redis is an in-memory database, meaning it stores and retrieves data directly from RAM instead of relying on a hard disk like traditional databases. Technically, it can persist data to disk for backup, but during runtime, all reads and writes happen in memory.

Redis is like keeping your snacks on the desk instead of in the kitchen — grabbing them is much faster than walking to the kitchen every time.

Key Components of a Redis Server

(Skipping the persistence layer for now)

• Request Handler: The entry and exit point of Redis. It receives incoming requests, processes or routes them internally, and returns the response.

• In Memory Data Store: Where Redis stores data as key-value pairs for ultra-fast access.

• Replication: Responsible for syncing the in-memory data to replica servers when replication is enabled.

Why to use Redis?

Asking “why” about anything is a great habit — it shows curiosity about how something works and the benefits it offers. The same goes for Redis. If there’s no clear advantage to using it, then what’s the point, right?

So, let’s start with the “why.” We should use Redis because it’s incredibly fast — it stores data in memory — and it efficiently reduces the load on the server by caching frequently accessed data.

Accessing the data (Example)

Without Redis

I’ve created a simple api to fetch product data from 'https://dummyjson.com/products/1'.

Now, I’ll try to call the api for the first time the response took 290 ms and for subsequent requests the response time is ~150 ms.

Normally, it took around 150–200 ms for a response — that’s our average baseline. Now, I’ll make a quick update and add a Redis caching layer, which is just a couple of lines of code.

With Redis

In the snippet, I’ve added the line:

const product = await redis.get(`product:${id}`);

This checks if the product with the given id already exists in the Redis cache. If it does, we return it immediately; if not, we make the API call and then store the result in Redis for future requests.

So what has changed?

Let’s make an API call and check the response time. For the first call, we get roughly the same result — around 265 ms.

You might be thinking, “Well, that’s the same as before, so what’s the point of integrating Redis?” But hold on — let’s call the API again and see what happens. This time, it’s just 5 ms. A bug? Nope. This is exactly what Redis helps us achieve. The first call was slow because the data wasn’t in the cache — a cache miss — so we had to make the API request. The second call was a cache hit, meaning the data came straight from Redis, giving us an almost instant response.
With Redis the sebsequent requests took ~6 ms that is 15-20x faster.

Architecture - API flow

Now that we’ve seen how an API behaves with and without Redis, let’s look at what’s actually happening behind the scenes. The diagram below illustrates the request–response flow:

Request/ Response Flow

1. The client sends a request to the server.

2. The server checks the Redis cache.

3. If found → skip to step 6 (cache hit).

4. If not found → the server queries the database (cache miss).

5. The server stores the fetched data in Redis for future requests.

6. The server returns the response to the client.

Conclusion

In conclusion, I’ve provided a brief overview and a working example of Redis. We explored what Redis is, why it’s used, and compared an API implementation with and without Redis. Redis is a powerful tool for achieving sub-second response times and is widely adopted across various products and applications. It not only accelerates requests but also reduces the load on databases and servers. While it’s fast and efficient, it’s most beneficial for scenarios involving large datasets rather than small key-value pairs. Additionally, Redis primarily stores data as strings (commonly JSON), so its usage should be planned with this in mind. We’ll explore more examples in upcoming posts.