Multi-Tenancy

Multi-tenant architecture is a powerful way to serve multiple customers from a single, shared application instance. It’s efficient and scalable, but it introduces a significant challenge: when a bug occurs for just one tenant, how do you debug it without disrupting everyone else? Reproducing the issue can be a nightmare of sifting through logs and guessing at tenant-specific configurations.

This is where ASP.NET Core’s middleware pipeline becomes your secret weapon. By creating a small, targeted piece of custom middleware, you can build a powerful debugging toolkit that provides deep visibility into tenant-specific requests on demand. In this post, we’ll walk through how to build a middleware component that helps you zero in on those elusive, tenant-specific bugs.

The Unique Challenge of Debugging Multi-Tenant APIs

In a standard single-tenant application, if a bug exists, it usually affects all users in the same way. In a multi-tenant world, the landscape is far more complex:

• Configuration Differences: Tenant A might have a feature flag enabled that Tenant B doesn’t.
• Data Isolation: The exact data being processed for Tenant A could trigger an edge case that Tenant B’s data never will.
• Custom Workflows: Some tenants might have unique integrations or settings that alter the application’s behavior.
• Logging Noise: A centralized logging system can make it difficult to isolate the sequence of events for a single tenant’s problematic …

Building a multi-tenant SaaS application presents unique challenges, especially when it comes to data isolation. One of the most common and robust approaches is the “database-per-tenant” model, where each customer’s data resides in its own dedicated database. This ensures strong security and simplifies scaling.

The core problem, however, is telling your application which database to connect to for any given HTTP request. A static connection string in appsettings.json won’t work. We need a dynamic, request-aware mechanism. This is where ASP.NET Core middleware shines. By intercepting requests early, we can identify the tenant, retrieve their specific connection string, and configure services for the remainder of the request pipeline.

In this post, we’ll walk through building a middleware-based solution to manage tenant-aware connection strings in an ASP.NET Core application.

The Challenge with Static Configuration

In a typical single-tenant application, you register your DbContext like this:

// Program.cs - The traditional way
var connectionString = builder.Configuration.GetConnectionString("DefaultConnection");
builder.Services.AddDbContext<ApplicationDbContext>(options =>
    options.UseSqlServer(connectionString));

This works because the connection string is known at startup and never changes. In a multi-tenant world, the connection string depends on who is making the request, a detail that is only available once the HTTP …

Building multi-tenant applications, a common pattern for Software as a Service (SaaS) products, introduces a fundamental challenge: how do you know which tenant is making the current request? Every incoming call to your API or web app must be correctly associated with a specific tenant to ensure data isolation and deliver a customized experience. The answer lies in a clean, powerful pattern: per-request tenant resolution using custom middleware.

In this guide, we’ll walk through creating a robust tenant resolution strategy in ASP.NET Core. We’ll build custom middleware that identifies the tenant from the incoming request and makes that information available to the rest of the application through dependency injection.

The Goal: What is Tenant Resolution?

At its core, tenant resolution is the process of inspecting an incoming HttpContext to extract a unique tenant identifier. Once you have this identifier, you can use it to look up the tenant’s details (like their database connection string, theme information, or feature flags) and load them into a request-scoped context.

There are several common strategies for identifying a tenant:

• Hostname/Subdomain: tenant1.yourapp.com, tenant2.yourapp.com
• URL Path: yourapp.com/tenants/tenant1/
• HTTP Header: X-Tenant-Id: tenant1
• Query String: yourapp.com/products?tenantId=tenant1

The beauty of the middleware approach is that it centralizes this logic, making your application cleaner and easier to maintain, regardless of …

In modern web development, Cross-Origin Resource Sharing (CORS) is a fundamental security mechanism. For standard, single-client applications, configuring a CORS policy in ASP.NET Core is straightforward: you define a set of allowed origins in your Program.cs. But what happens when you’re building a multi-tenant application where each tenant needs a different set of allowed origins?

A static, hardcoded list of origins quickly becomes a bottleneck. Adding a new tenant or updating a tenant’s domain would require a code change and a redeployment. This is not scalable or secure. The solution is to create a dynamic, per-tenant CORS policy that resolves the correct origins at runtime.

In this post, we’ll build a custom ASP.NET Core middleware to achieve exactly that. We’ll create a flexible system that looks up a tenant’s specific CORS configuration on the fly for each incoming request.

The Problem with Static CORS in Multi-Tenant Architectures

Let’s quickly review the standard approach. In a typical Program.cs, you might see this:

builder.Services.AddCors(options =>
{
    options.AddDefaultPolicy(policy =>
    {
        policy.WithOrigins("[https://client-app-one.com](https://client-app-one.com)", "[https://client-app-two.com](https://client-app-two.com)")
              .AllowAnyHeader()
              .AllowAnyMethod();
    });
});

// ... in the pipeline configuration
app.UseCors();

This works perfectly for a predictable …

I once spent the better part of a week chasing a bug that only appeared in our staging environment under heavy load. A user from one organization would suddenly see data belonging to another. We’d check the logs, query the database directly, and everything looked fine. It was a ghost.

The culprit? A single line change someone made to “optimize” our database access: switching AddDbContext to AddDbContextPool. That optimization introduced a state-sharing bug that was nearly impossible to reproduce locally.

DbContext pooling in EF Core is one of those features that promises a big performance win, but it comes with a massive, sneaky gotcha. Let’s break down what it is, where it shines, and how to use it without shooting yourself in the foot.

So, what’s DbContext pooling anyway?

Normally, when you register your DbContext in an ASP.NET Core app, you use a scoped lifetime. This is the default and the safest option.

// The standard, safe way: A new instance for every HTTP request.
services.AddDbContext<AppDbContext>(options => 
    options.UseSqlServer(connectionString));

This means for every single web request, the dependency injection container creates a brand-new DbContext instance. When the request is over, that instance is thrown away. Simple, clean, and isolated.

DbContext pooling changes the game. Instead of creating a new instance every time, it keeps a “pool” of DbContext instances ready to go.

// The high-performance way: …