Newest first, grouped by year. Search or filter by topic.
Nine parts of architecture posts lie by omission unless the tenth is the ledger. What earned its keep — isolation as data, MaxTenants = 1, the schema-keyed model cache — and the honest list of shortcuts: plaintext connection strings, cache windows, reflection, and a fan-out loop that still says TODO.
Seven parts of migration machinery existed to deliver one table — a hierarchical crumb trail with three ltree columns, a jsonb payload, GiST and GIN indexes, and a Dapper read side that speaks PostgreSQL's native operators. This is why it was PostgreSQL all along.
Shipping a migration to one database is a deploy step. Shipping it to every schema in every group database is an orchestration problem — cross-database MigrateAsync, an HTTP migration surface, a per-tenant audit ledger, and the honest gap where the fan-out loop should be.
Deleting a tenant is the most dangerous button in the platform — behind it sit DROP SCHEMA CASCADE and DROP DATABASE. A two-step lifecycle with global query filters, a SaveChanges interception and an explicit purge keeps the blast radius survivable.
Tenants are data too. The tenant-management database is the one single-tenant database in the whole platform, and its five entities — Tenant, TenantConnection, TenantFeature, DatabaseGroup, TenantMigrationHistory — carry every decision the rest of the series depends on.
A signup click becomes a real PostgreSQL database or schema in seconds. Running CREATE DATABASE from application code feels illegal until you contain it — identifier validation, quoted DDL, idempotent steps, and a status machine that admits when provisioning fails.
You built schema-aware migrations, provisioned tenant A, and everything worked. Tenant B provisions without a single error — and gets no tables. EF Core's model cache is the silent culprit, and IModelCacheKeyFactory is the three-field fix.
EF Core wants one database, one model and one migrations history table. Schema-per-tenant breaks all three assumptions. Constructor-injected migrations, a per-schema history table and a replaced IMigrationsAssembly put one migration set in charge of every tenant schema.
Header, route, subdomain or query string: how the platform decides who is asking before it touches any data, how tenant identity becomes a connection string and a schema, and where the caching knives are hidden.
Database-per-tenant, schema-per-tenant, or packed into a shared database? Kicking off a series on building a multi-tenant platform where one EF Core codebase supports all three isolation strategies behind a single control plane.
Lessons from migrating a multi-tier .NET Framework monolith to .NET microservices on Azure Kubernetes Service: what to split first, what to leave alone, and the manifests that hold it together.
