5

I'm working on building a multi tenant application which relies on redis as a cache. I'm currently researching a feasible way to achieve multi tenancy with redis. I see that redis enterprise offers multi tenant support, however I'm looking to take advantage of AWS ElasticCache which doesn't offer redis enterprise version (as far as I know), so I'm wondering if there are any other viable alternatives.

I think the easiest solution would be to simply prepend all keys with a "tenant ID" at the application layer to keep data from each tenant separated and have all data stored on a single redis cluster. The application would write and read data based on the current tenant and prepending the correct ID.

Is there any issues with this approach, or are there any other viable solutions without using redis enterprise?

8
  • 1
    Do you have a backing database? What multitenant strategy are you using there (one database with tenant ids, multiple databases in one server, multiple servers)? Is there a reason why you can't use an analogous strategy between Redis and your database?
    – Thomas Owens
    Commented Sep 10, 2019 at 16:39
  • Honestly, that sounds like the approach I would take. The biggest thing with Redis is making sure keys that should be unique are. Another option is to simply use GUIDs, which are fairly opaque but globally unique. If you are trying to debug, then having a key that provides additional information (like tenant) is useful. Commented Sep 10, 2019 at 16:39
  • @ThomasOwens The RDS database uses a database-per-tenant in one server. There is no equivalent on redis without redis enterprise as far as I know.
    – Brad
    Commented Sep 10, 2019 at 17:19
  • @BerinLoritsch My tenant ID's are GUIDS. So each key in redis would look like xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx-KEY-NAME-HERE. It might be difficult to debug but would be guaranteed unique per tenant
    – Brad
    Commented Sep 10, 2019 at 17:20
  • @Brad Redis supports multiple databases via the URL. The default is 16 but can be increased in the conf file
    – Thomas Owens
    Commented Sep 10, 2019 at 17:22

1 Answer 1

5

After further research I am satisfied with an answer so I will answer my own post.

I see that Microsoft recommends using a prepended-tenant (client ID in this case) in this particular article: https://docs.microsoft.com/en-us/azure/architecture/multitenant-identity/token-cache

Furthermore, I see that the framework I'm using has specific options & code to prepend a string for separating apps/services so it seems like this is a common practice. I am satisfied with this information so I will go with this option.

2
  • Might be running into this scenario myself. Its good to know that the simple approach (prepending the tenant ID) works well.
    – GHP
    Commented Sep 10, 2019 at 21:22
  • What about the security? how are you restricting one client from accessing other clients's data? are you creating separate creds for each client? Commented Aug 17, 2022 at 10:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.