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?

Brad
  • 425
  • 6
  • 11
  • 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 Sep 10 '19 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. – Berin Loritsch Sep 10 '19 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 Sep 10 '19 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 Sep 10 '19 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 Sep 10 '19 at 17:22
  • @ThomasOwens that sounds like it would work great. However some quick googling make it seem like that feature is deprecated and I can't find any mention of that on the redis docs. Can you provide any links to some reference material? – Brad Sep 10 '19 at 17:26
  • This article seems to suggest that prepending keys with a tenant ID is feasible. https://docs.microsoft.com/en-us/azure/architecture/multitenant-identity/token-cache – Brad Sep 10 '19 at 17:36
  • @Brad You're right. I stood up a Redis instance just a couple of months ago and it was in the docs without anything being deprecated, but I am seeing posts from 2017 saying it is. Not sure if the databases is the way to go at this point, so the key-based approach is probably what you want. Unless you want a Redis instance per tenant, of course, but that's probably too much infrastructure. – Thomas Owens Sep 10 '19 at 17:58

1 Answers1

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.

Brad
  • 425
  • 6
  • 11
  • Might be running into this scenario myself. Its good to know that the simple approach (prepending the tenant ID) works well. – Graham Sep 10 '19 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? – Jerald Baker Aug 17 '22 at 10:25