Skip to content
Part 1 · 5th January 2025Jeremy on Multi-Tenancy with CodeOpinionJeremy joins Derek Comartin of CodeOpinion for a wide ranging conversation on multi-tenancy strategies.
Part 2 · 28th July 2026Onboard a Tenant Without a Deployment: Runtime Multi-Tenancy in CritterWatchCritter Stack services can add, disable, and remove tenants at runtime — new databases and all. CritterWatch turns that capability into an operator console: a tenant lifecycle you can drive from a browser, and performance metrics broken down per tenant id.
Part 3 · 4th August 2026One Application, Many Brokers: Wolverine's Multi-Transport and Broker-per-Tenant StoryReal systems rarely get to standardize on one message broker. Wolverine lets a single application speak Rabbit MQ, Azure Service Bus, Kafka, and MQTT at once — and takes it one step further with a broker-per-tenant model where the tenant id is inferred from the connection a message arrived on and carried all the way into the database transaction.Part 4 · 22nd September 2026Multi-Tenancy with EF Core is a Whole Lot Easier with WolverineEF Core query filters and dynamic connection strings are the raw ingredients for multi-tenancy. Wolverine turns them into a finished dish: conjoined tenancy with zero filter plumbing, database per tenant, tenants added at runtime, HTTP tenant detection that flows straight into DbContext construction, a transactional inbox/outbox per tenant database, tenant ids that ride along on every cascaded message, and 'it just works' schema migrations across every tenant database.Part 5 · 7th October 2026Wolverine's End to End Multi-TenancyWolverine treats the tenant id as message metadata, and that one decision carries the tenant from HTTP detection, into the right Marten, Polecat, or EF Core session, onto every cascaded message, and into the only transactional inbox and outbox in .NET that lives in each tenant's own database. Here's how the whole chain works, and why it took years to get right.
Multi-Tenancy in the Critter Stack
The Multi-Tenancy in the Critter Stack series
Part 1 · 5th January 2025Jeremy on Multi-Tenancy with CodeOpinionJeremy joins Derek Comartin of CodeOpinion for a wide ranging conversation on multi-tenancy strategies.Part 2 · 28th July 2026Onboard a Tenant Without a Deployment: Runtime Multi-Tenancy in CritterWatchCritter Stack services can add, disable, and remove tenants at runtime — new databases and all. CritterWatch turns that capability into an operator console: a tenant lifecycle you can drive from a browser, and performance metrics broken down per tenant id.Part 3 · 4th August 2026One Application, Many Brokers: Wolverine's Multi-Transport and Broker-per-Tenant StoryReal systems rarely get to standardize on one message broker. Wolverine lets a single application speak Rabbit MQ, Azure Service Bus, Kafka, and MQTT at once — and takes it one step further with a broker-per-tenant model where the tenant id is inferred from the connection a message arrived on and carried all the way into the database transaction.Part 4 · 22nd September 2026Multi-Tenancy with EF Core is a Whole Lot Easier with WolverineEF Core query filters and dynamic connection strings are the raw ingredients for multi-tenancy. Wolverine turns them into a finished dish: conjoined tenancy with zero filter plumbing, database per tenant, tenants added at runtime, HTTP tenant detection that flows straight into DbContext construction, a transactional inbox/outbox per tenant database, tenant ids that ride along on every cascaded message, and 'it just works' schema migrations across every tenant database.Part 5 · 7th October 2026Wolverine's End to End Multi-TenancyWolverine treats the tenant id as message metadata, and that one decision carries the tenant from HTTP detection, into the right Marten, Polecat, or EF Core session, onto every cascaded message, and into the only transactional inbox and outbox in .NET that lives in each tenant's own database. Here's how the whole chain works, and why it took years to get right.