Tenant Isolation in a Modular Monolith

The failure mode

Multi-tenant bugs are quiet. A query without a tenant filter still returns rows, the page still renders, and the leak is discovered by a customer. Code review alone will not catch every case.

Three places to enforce it

• Data access: route reads through one query layer that applies the tenant scope by default, so opting out is the exception that has to be justified.
• Request context: resolve the tenant once per request, from the authenticated user, a header, a subdomain, or the session, and make it available everywhere.
• Writes: reject or flag any write that arrives without tenant context.

Roll enforcement out in stages

Turning strict enforcement on in a large existing codebase breaks things. A safer path is to run the guard in a shadow mode that only logs violations, fix what it finds, switch to active mode for the paths you trust, and finally strict. A circuit breaker that degrades the guard under load protects availability while you do this.

Measure coverage

Classify every table as tenant-scoped or global, and report how many are actually covered. A coverage number tells you where the next leak is likely to be; a checklist does not.

Why a modular monolith helps

With one deployable and modules that talk through contracts, the query layer and the request context live in one place. You can enforce isolation once, instead of in every service.

How we do it

RumuzePMO resolves a tenant context per request, applies tenant scoping through its query engine, and ships commands to classify tables, validate integrity, and report enforcement coverage. Its write-protection middleware can run in shadow, active, or strict mode.