Just wanted to double check that there isn’t an officially supported multitenancy story in the pipeline before investing time in testing our hand rolled solution.
We use stream-prefix and acl, no need for separate storage, happy to take input if there are other things to consider.
/Peter
We have looked at multi-tenancy in the past. There are many possible options and it depends completely on the level of isolation needed. Can you say more about your ideal situation?
We have no formal requirements at this point, other than general data safety (in EU so GDPR applies). We’re just trying to get our hosting as efficient as possible, and moving smaller customers to a clustered environment, where we can’t justify three separate VM’s per per tenant.
From a developer perspective I think passing some kind of tenant/‘database’ identifier to the connection builder would be the easiest solution. As transparent as possible basically. (We also have existing systems running on-prem, and to avoid datamigration I’ve made a bit of hack to turn multi tenancy on and off). Most relational and document db’s have some notion of separate databases, so probably coloured by 20 years of working with those terms, there could be better solutions I’m not aware of.
We’re trying to go live in a few months, so unless you had something ready for release in a few weeks, I’ll stick with my homegrown solution for now, but I’m happy to continue the discussion. We’re not cloud scale so I guess our priorities would be different from those who are…
/Peter
this really isn’t ideal, but if you needed this right now you could simply prefix all streamNames with the tenant id.
Yep, thats what I’ve done.
/Peter
In my POC I have just added a TenantId property in the base event class. Then of course any consumer would need to set the context for the tenant before handling/applying the event.