Database-per-tenant multi-tenancy with Aspire

[jmezach]

We are looking to implement a database-per-tenant multi-tenancy model with Aspire. At the moment we have a central "configuration" database which contains the connection strings for multiple databases and some of those databases exist multiple times, one for each tenant. From the applications perspective we would like to have the connection strings for those databases injected with some kind of convention, something like -, ie: HumanResources-TENANT1, HumanResources-TENANT2, etc.

We're struggling a bit with how to implement this in Aspire, mostly because we first want to prompt for the connection string to the configuration database and then once we have that we would need to fetch the relevant connection strings from there. But as far as I know we can't add additional resources to the model once it is running. What we would like to do is something like this:

var builder = DistributedApplication.CreateBuilder(args);

var configurationDatabase = builder.AddConnectionString("ConfigurationDatabase");

var humanResourcesDatabase = builder.AddTenantedConnectionString("HumanResources")
    .WithReference(configurationDatabase);

var api = builder.AddProject<Projects.Api>("api")
    .WithReference(humanResourcesDatabase);

builder.Build().Run();

And then our API would get connection strings injected for each tenant.

As far as I can tell there isn't a way to implement this currently. What I think we're looking for is an IResourceWithMultipleConnectionStrings, but that doesn't exist today. But maybe I'm missing something?

[davidfowl]

Are tenant databases provisioned at runtime or by some other process?

[jmezach]

I'll have to dive a bit into how WithReference currently works I guess, but I think it makes sense. I'll give it a shot and see what I can come up with. Thanks for the help so far. I'll post back here if I can get it to work :).

[jmezach]

I've managed to implement something that works for our scenario. I've added a TenantedConnectionStringResource and a corresponding AddTenantedConnectionString method. Then I've added a WithReference method that associates the TenantedConnectionStringResource with the configuration database by subscribing to its ResourceReadyEvent. When that fires I've load the tenant specific connection strings and add them to a dictionary on the TenantedConnectionStringResource. Finally I've added a WithReference method that associates the TenantedConnectionStringResource with any resource that implements IResourceWithEnvironment. There I inject all the relevant connection strings into the target resource.

[KennethHoff]

Would you be willing to share this code with the class?

[davidfowl]

@jmezach beautiful!

[jmezach]

@KennethHoff Sure, here's the Gist: https://gist.github.com/jmezach/08ec8e54aea2b531bdb661f0949bc0c3. This example can be further enhanced with some proper status updates to the dashboard of course, but it should work as is.

[YohanSciubukgian]

We’d love to see the Aspire documentation evolve to include robust multitenancy guidance, complemented by dedicated sample implementations that illustrate best practices for both shared (e.g., shared databases) and dedicated (e.g., dedicated databases with shared APIs) resource models. This would be especially valuable for key infrastructure components such as identity and access management (e.g., Keycloak, Entra), databases (e.g., Cosmos DB, PostgreSQL, Redis), message brokers (Azure Service Bus, MQTT, etc.), and other common services.

We’ve been leveraging the Azure Multitenant Solutions Architecture Guide as a foundational reference. It offers a great breakdown of common scenarios across various Azure services. Having a similar resource tailored to Aspire for Azure and Open Source services would help bridge the gap between architectural guidance and implementation using Aspire. It would be a tremendous asset for teams planning or executing migration strategies with Aspire.

---

Additionally, it would be valuable to showcase strategies for achieving zero-downtime deployments, such as blue/green deployments (and rollback strategy; should it be using a gitops like strategy) in a generalized way that applies across hosting platforms like Azure App Services, Azure Container Apps (ACA), Azure Kubernetes Service (AKS), Kubernetes, and Docker, all using the Aspire framework deployment pipelines.