Different Redis Usage Scenarios in our MicroService Architecture

Hello everyone,

In this story, I’m going to describe how we use Redis in our system by giving five different approach. Before that, let me give a brief introduction of the system.

At the beginning of the division of our monolith legacy system, of course, we followed Domain Driven Design principles. When we dive into technical dept, we saw some boilerplate usage on local caching and sharing data in every instance. Caching and sticky session might be potential problem on microservice transformation.

1. Redis Crud Repository

On local cache, we have some contents such as page label, property, error message detail and any other details for almost 100 pages. In every instance, local cache is refreshed for every page. However, adding 100 pages in every microservice are not necessary. Some of microservices need maybe 20 or just 1 according to its domain.

To manage these page informations, we developed one microservice application to retrieve page contents, check updates, push data into Redis and notify other microservices on some of pages are refreshed. To do this, first, entity was generated. In this class, TypeAlias was used for eliminating path conflict on package folder in other microservices.

And repository class is generated

After retrieving Page Contents from the service, operations of page update were completed by using RedisPageManagerRepository.

2. Redis Pub/Sub

First approach was completed, but now we want to notify other microservices to retrieve updated content on their local cache because of avoiding Redis I/O cost in every request.

We could use Kafka, but as you know, Kafka works on consumer group and we did not want to break this functionality and duplicate event based operations in every pod. So, we prefer to use Redis Pub/Sub. It works on fire and forget and also, we can notify every subscribers on channel.

At configuration, we add channelTopic

In Publisher Service, updated Page List comes from in section 1 and we published data.

On Consumer side

Configuration:

You can also make your listener a service and add dependency. It’s totally up to your architecture. In our case, we transform listener as a service and update our data.

Thus, 2 different Redis usage was completed in one scenario.

3. RedisTemplate

In our domain and business, we need to store some data in microservices. But we do not want to create bunch of data per session and they will be totally independent. According to data and domain, we need different requirements for time-to-live, mobile, web and app session and BFF approach.

For example, you make a request from mobile application and retrieve data from X microservice by the way X microservice’s data is rarely updated. This data is stored in Redis’ special key. Thus, as same user if you send a same request from web, X microservice returns same data from Redis. As a result of this, you do not need to complete same business logic.

The main reason why we use RedisTemplate in this case is controlling and manipulating data per domain. Any type of data can be stored in Redis with different expire time range.

4. Redis Cacheable

So far, everything is fine in our microservices. However, we need to increase our ability to work with non-user based cache values. So we use RedisCacheManager to store data in Redis by using Spring Cacheable.

We have already used local cache to store some data in every microservice, so added Primary annotation to it. To utilize power of Redis Cacheable, we should use CacheConfig annotation to indicate which cache will be used. With the contribution of this approach, we can easily cache non-user based cache data without using RedisTemplate.

5. Redis Stream

In last case, I will mention Stream Redis. When Redis Pub/Sub or Kafka is used, main approaches notify other services and then lost published information which is fire and forget. Because of these infrastructure, some of problems can be occurred such as down of services and loss data on some subscriber or application.

With Redis Stream, you can track this data. Let’s assume you have a application and you want to catch user behavior on your system for example people read some magazines or news on your app. At first you save data, then maybe run the job and analyze the user and give feedback on new access. By using Redis Stream, real time data process with stream data.

Let’s reorganize above case. User read magazine and magazine detail for user is published as stream. Recommendation engine on consumer side listen event and analyze it, finally give recommendation on session. You can also follow this approach with Kafka, but Redis Stream keeps stream data till consumer side give acknowledgement and also you cannot miss data for user history. After that, when user interact with different page, your recommendation shows up.

Let’s dive into code :)

Publisher service

Consumer Side

Service Logic

Whether error shows up in process, there is nothing worry about. You can check pending messages with

In this story, I tried to mention 5 different usage of Redis in application. I hope it will be helpful. If you like story please CLAP :)