Designing Blazor Server Architecture for enterprise applications requires more than wiring up a few Razor components. Enterprise workloads bring multi-tenancy, long-lived user sessions, background work, security boundaries, and dozens of developers sharing one codebase. This article covers the architecture decisions that separate a demo from a system that runs a real business for years.
We look at modular composition, per-circuit service boundaries, tenant isolation, long-running circuits, and the operational concerns that appear the moment you deploy. Every pattern here is applied in the Indotalent CRM, HRM, and WMS codebases, which are shipped as Blazor Server applications.
Designing the Blazor Server Architecture Foundation
The foundation of an enterprise Blazor Server application is a clean composition root and a disciplined project structure. Indotalent uses Vertical Slice Architecture: each business feature — a contract, a screen, a MediatR handler, a data query — lives in one slice. Components stay thin; they call handlers, and handlers own the business rules.
This pays off fast. When ten developers work on ten features, they rarely touch the same files. When a feature changes, you change one slice. And because every slice is a closed unit, it can be unit tested without spinning up a browser or an entire hosting environment.
Scoped Services as Per-Circuit Boundaries in Blazor Server Architecture
In Blazor Server, each circuit gets its own dependency injection scope. That is the architectural keystone of the whole model: the scope is the unit of user state. Register a user context, a tenant context, and a DbContext as Scoped, and every component in the circuit resolves the same instances.
Here is a tenant context that is created once per circuit and initialized on login:
public sealed class TenantContext
{
public Guid TenantId { get; private set; }
public string ConnectionString { get; private set; } = string.Empty;
public void Initialize(Guid tenantId, string connectionString)
{
TenantId = tenantId;
ConnectionString = connectionString;
}
}
builder.Services.AddScoped<TenantContext>();
builder.Services.AddScoped<AppDbContext>();
Because the context is scoped, any component — a page, a sidebar, a lookup dialog — reads the same tenant without threading a parameter through the component tree. New components can be added without changing existing signatures, and the context is disposed automatically when the circuit ends.
Multi-Tenancy in a Blazor Server Application
Multi-tenant SaaS needs tenant isolation at every layer. With per-circuit scoped services, tenant resolution happens once when the circuit opens, and everything downstream trusts the scoped context instead of re-deriving the tenant from query strings or headers.
- Database-per-tenant: build the connection string in the tenant context and register a scoped DbContext factory
- Shared database with tenant filters: add a global query filter that reads the scoped TenantId
- Tenant-keyed caches: prefix Redis or memory cache keys with the tenant id
- Audit and logging: stamp every log and audit row with the tenant id from the scoped context
The key rule is that nothing global may ever assume a single tenant. A Singleton cache that ignores the tenant is a data leak waiting to happen, and it is exactly the kind of bug that surfaces only after a second customer signs up.
Long-Running Circuits and Background Work
A circuit can stay open for hours. That means background work must not be tied to a single circuit. Fire-and-forget tasks launched on a scoped service die when the circuit dies, and singletons that capture scoped services create captive dependencies that leak connections and state.
Prefer hosted services (BackgroundService) for email dispatch, report generation, and integration jobs. Components should enqueue work to the hosted service and poll or subscribe for completion — never block a circuit waiting on an external API that might take minutes. If a long operation must run in the circuit, wrap it in an async flow with a cancellation token so it can be abandoned cleanly when the user navigates away.
Security and the Enterprise Perimeter
Because Blazor Server code runs entirely on the server, the security model is closer to an API than a single-page application. Authentication and authorization run inside the component pipeline, so [Authorize] attributes, policy checks, and scoped claims all behave the way ASP.NET Core developers already expect.
Add layers in this order: authenticate at the endpoint, resolve the tenant and user into scoped contexts, authorize every MediatR request with a policy or guard, and validate every input before it touches a database. Indotalent products pair JWT authentication with ASP.NET Core Identity and enforce authorization at the handler level, so a component can never bypass the rules.
Key Takeaways
- The circuit scope is the unit of user state in enterprise Blazor Server Architecture
- Scoped services give every circuit a consistent tenant and user context
- Multi-tenancy works by resolving the tenant once per circuit and filtering everywhere else
- Hosted services, not circuits, should run background work
- Vertical slices keep large teams productive in a single codebase
FAQ
Should the DbContext be Scoped or created per operation in Blazor Server?
Scoped. It is created once per circuit and disposed when the circuit ends. Register it with AddScoped and let the dependency injection container manage its lifetime; never cache it in a Singleton.
How do you resolve the tenant before rendering?
Use a circuit-aware component or middleware that reads the authenticated user and calls Initialize on a scoped TenantContext before the first render of the circuit. After that, every component reads the same instance.
What happens to scoped services when a user refreshes the page?
Refreshing closes the old circuit and opens a new one, so scoped services are recreated. That is why you must re-initialize context from the stored session rather than relying on in-memory component state.
Is Blazor Server secure enough for regulated industries?
Yes, and in some ways safer than a WebAssembly app, because business logic and secrets never reach the browser. The standard ASP.NET Core security stack applies unchanged.