Skip to content

Question: Does Spring Data Redis Support Runtime Multi-Tenancy for Redis Key Prefixing? #3130

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
srosio opened this issue Apr 7, 2025 · 1 comment
Assignees
Labels
for: stackoverflow A question that's better suited to stackoverflow.com status: declined A suggestion or change that we don't feel we should currently apply

Comments

@srosio
Copy link

srosio commented Apr 7, 2025

Hi Spring Data Redis Team,

I’m working on a multi-tenant application using Redis, and I need to ensure that Redis keys are prefixed with the tenant context (e.g., tenantA:User:123) to isolate data per tenant. However, I’ve been struggling with managing key prefixing through custom solutions, and it’s proving to be error-prone and difficult to maintain across various Redis operations.

My Question:

  • Does Spring Data Redis have built-in support for runtime multi-tenancy or a way to automatically apply tenant-aware key prefixing across all Redis operations (e.g., SADD, SMEMBERS, HSET, etc.) based on the current tenant context?
  • If not, is there an existing recommended approach to achieve this that doesn’t require extensive manual configuration or custom serializers?

I believe this functionality would be very beneficial for multi-tenant applications, and I would appreciate any advice or resources on how to implement this more effectively.

Thank you for your time and assistance!

@christophstrobl
Copy link
Member

Thank you for reaching out.
Spring Data Redis does not offer any built in solution for this kind of scenario and likely never will.

As you already mentioned there's a variety of potential solutions ranging from a custom RedisSerializer for keys to subclassing or creating proxies. I'm sorry there is not the one recommended solution as all of the mentioned have their own requirements/limitations.

However, it feels like this is a question that would be better suited for Stack Overflow. We prefer to use GitHub issues only for bugs and enhancements. Feel free to update this issue with a link to the re-posted question (so that other people can find it).

@christophstrobl christophstrobl closed this as not planned Won't fix, can't repro, duplicate, stale Jun 4, 2025
@christophstrobl christophstrobl added status: declined A suggestion or change that we don't feel we should currently apply for: stackoverflow A question that's better suited to stackoverflow.com and removed status: waiting-for-triage An issue we've not yet triaged labels Jun 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for: stackoverflow A question that's better suited to stackoverflow.com status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

No branches or pull requests

3 participants