Strict tenant isolation in a multi-tenant data layer

WHAT THIS TESTS The interviewer wants to see that you know the spectrum of isolation models, can choose by risk, and apply defense in depth, because when tenants are competitors a single leak is catastrophic.

A GOOD ANSWER COVERS Name the models: silo (a database or schema per tenant) gives the strongest isolation and easy per-tenant backup and compliance, at higher cost and operational overhead; pool (one shared schema with a tenant id column) is cheapest and most scalable but leans hardest on correct scoping; bridge is a hybrid, for example separate schemas in a shared database. Given competitor-grade sensitivity, favor stronger isolation for the most sensitive data and enforce tenant scoping at multiple layers rather than trusting application WHERE clauses. Database row-level security ties every query to the authenticated tenant so a forgotten filter cannot leak rows. Add encryption with per-tenant key separation, least-privilege access, and audit logging of cross-tenant access attempts. Test isolation explicitly with automated checks that one tenant cannot read another's data.

COMMON WRONG ANSWERS Using only an application-level tenant filter as the single boundary, which fails the moment a query forgets the predicate or an injection bypasses it. Assuming pool isolation is automatically safe. Ignoring encryption and audit. Treating isolation as a one-time design rather than something to test continuously.

LIKELY FOLLOW-UPS When is silo worth the cost over pool? How does row-level security work? How do you prevent a noisy-neighbor tenant from degrading others?

ONE CONCRETE EXAMPLE For a pooled Postgres design, every tenant table carries a tenant_id, and row-level security policies restrict each connection to its tenant via a session variable set from the verified token. Even if a developer writes a query without an explicit tenant filter, the database itself returns only that tenant's rows. The most sensitive tables for the largest competitors are additionally placed in dedicated schemas, and an automated test suite asserts tenant A can never read tenant B's data.