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.
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.
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.
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.
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.
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.
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.
Pick the one closest to the role. Each is two pages and carries the same facts.
Applied AI
Agentic AI & Cloud Engineer · multi-agent systems, RAG and MCP on AWS
Cloud & .NET
C#, .NET 10 and ASP.NET Core microservices on AWS and Azure · Terraform & AWS CDK
Data Engineering
AWS lakehouse · Kinesis, Glue (PySpark), Apache Iceberg, Lake Formation
Everything
All three domains, with the standout project from each