Redis in microservices environment

[Navin Kaushik]

Hello All,

I need your opinion on below mentioned design decision in microservices environment: 

Design Task:  There are multiple micro services, going to use redis. As of now, there is one redis instance, how data should be stored on redis. 

• Option 1:  Use service acronym as prefix like svc1_key1,   svc2 _key1 etc.
  • Pros:
    • Simplest way, no need to managed multiple numbered database.
  • Cons:
    • Performance bottleneck difficult to identify like culprit service who is creating a problem.
    • Migration may require traversing all keys.
    • More size is required due to longer key names.
• Option 2: Use numbered database like 0,1 etc.
  • Pros:
    • Good isolation, no prefix is required.
    • Better monitoring
  • Cons:
    • Need to manage numbered databases. 

In future, if we face issues, we may go for separate instance of redis for each or group of services like 2 services using one instance and another 2 services using another instance of redis. 

I am inclined to use Option 2 to begin with, what is your opinion ?

 -Thanks,

Navin

[Robert Kahlert]

The documentation for https://redis.io/commands/select/ says

In practical terms, Redis databases should be used to separate different keys belonging to the same application (if needed), and not to use a single Redis instance for multiple unrelated applications.

So I guess part of the question is the judgement call how unrelated the microservices are.

--cc 

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/redis-db/9082ac36-973f-4dcf-af42-3b733a2b7c76n%40googlegroups.com.

[Navin Kaushik]

Thanks for the response.  Application/solution is one but microservices are independent in nature from the development/release/upgrade perspective. 

As of now, I have decided to use different database/index for each microservice.

At the sametime, there is a flexibility that we can split the instance if required in future.  

[Manish Arora]

Another thought for your consideration. On day 1 - sunny day scenario - it would work. When you have an outage, or one micro service consumes more resources, how would you troubleshoot these scenarios. The best practice would be to have a dedicated database for each / micro service. This gets you bounded context as well. 

[David Maier (Redis)]

Hello,

a third option would be to use not just a dedicated database, but actually a dedicated Redis instance or cluster. You should really see the databases (e.g., SELECT 1 for selecting the first database) more as namespaces. Microservices should be loosely coupled, and the segregation reflects that service A might have different needs than service B. Here some examples/concerns: 

1. Service A might have quite some scalability needs, but service B might scale at a lower scale. A Redis Cluster per service allows you to scale aligned to the needs.

2. You want to achieve high cache hit ratios. Operations by service A might influence the performance of service B due to eviction.

3. A shared cache might lead to resource contention. Microservices are typically following a shared-nothing architectural approach.

In summary, my recommendation would be that one service that uses a cache and that is loosely coupled from another service should use a dedicated Redis instance (or cluster) for caching (or as its database - dependent on the use case) and not share it with another service. 

(An exception that jumps into my mind would be to cache requests/responses on the level of an API gateway that acts on top of multiple services. But the scope would then be to scale the API gateway itself and not just the service.)

Hope this makes sense.

Regards,

David

 

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/redis-db/17641e45-c404-4efb-a49b-48530e910b3cn%40googlegroups.com.

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.