Skip to main content

#multi-tenancy

Log entries with this tag, newest first.

  1. Decision recordRealtime transports

    SignalR between a cloud and its sites

    A hub that pushes changes from a cloud to on-premises sites is a security boundary and a lifecycle problem: who may connect, what each connection hears, how long an admission holds, and how a client comes back after the server closes it. The design note: a service-client policy, a group per tenant, a fifteen-second sweep with the same check requests get, and a client that starts itself again because automatic reconnect does not follow a server-side Abort.

    8 min read

  2. Decision recordMulti-tenant platforms

    A schema per tenant: the database owns the name

    When every tenant's rows live in a PostgreSQL schema of their own, the mapping from identifier to schema name is a security boundary. So the mapping moved into the database: a stored generated column, a unique index, COLLATE "C", and a plain CREATE SCHEMA as the claim on a new name. With the two error codes that mean 'taken', the one-at-a-time gate, and an EF Core pooling detail that only production-shaped tests found.

    10 min read

  3. Decision recordMulti-tenant platforms

    The tenant comes from the token, not from the header

    In a multi-tenant API the tenant a request acts in is decided from who is calling. A header may name one; the token says whether the caller may act there. The decision record: one middleware owns the header, the status code follows the caller, and authority that arrives through a replicated directory is trusted for one token lifetime.

    9 min read

  4. Platform

    Hexavera

    A workforce and access-control platform: its identity server, its multi-tenant cloud, and the gateway between the cloud and physical door controllers.

    • .NET 10 · Blazor · OpenIddict · PostgreSQL · .NET Aspire