The interview room
Design a multi-tenant analytics platform: isolated tenant data, shared compute. Cover isolation, cost allocation, and tenant-level RBAC. This is a platform/DE hybrid question. They want security instincts and FinOps instincts, not only a warehouse sketch.
First, the basics
Multi-tenancy
One platform serves many customers (tenants). Each tenant's data and users must not leak to others. Compute may be shared for cost efficiency, but data isolation is not optional.
Isolation dimensions
1. Storage/data: Can tenant A query tenant B's rows? Must be impossible by default. 2. Compute: Can tenant A's runaway query starve tenant B? 3. Access control: Roles inside a tenant (admin, analyst) plus platform operators. 4. Cost: Who pays for that 3AM full scan?
Shared tables with tenant_id filters
Beginners propose one big fact table and WHERE tenant_id = ?. That is fragile. One missing predicate in a view or a BI tool is a data breach. Prefer stronger boundaries: separate schemas/databases/accounts, plus policies as defense in depth.
Noisy neighbor
Shared warehouses without quotas mean one Cartesian join ruins everyone's dashboards. Multi-tenant design always includes fairness: concurrency limits, credit quotas, separate pools for enterprise tiers.
The problem
- Hard isolation of tenant data.
- Shared compute with fairness/budgets.
- Tenant RBAC and admin boundaries.
- Per-tenant cost visibility.
- Templated onboarding for new tenants.
- Scale from dozens to thousands of tenants.
- Possibly regional residency for some enterprises.
What good looks like
You separate storage isolation from compute pooling. You propose tiering (pooled vs dedicated warehouses). You describe RBAC. You show chargeback. You explain noisy-neighbor controls. You do not rely on "remember the WHERE clause."
Clarifying questions
- Do enterprise tenants require dedicated compute accounts?
- Data residency / region pinning?
- Are tenants SaaS customers or internal business units (similar patterns, different legal risk)?
- Interactive BI vs ELT heavy tenants?
- Need cross-tenant aggregated benchmarking (anonymized)?
Out of scope
- Full SaaS product billing UI.
- Designing the customer-facing application OLTP.
- Deep Kubernetes multi-tenant cluster hardening (mention only if compute is self-hosted Spark).
Why this question exists
SaaS analytics platforms die in two ways: a cross-tenant data leak, or a noisy neighbor that takes down shared compute. Security interviews often miss FinOps. Warehouse interviews often miss tenant boundaries. This prompt merges both.
Isolation is a spectrum (teach it)
Think in layers:
- Physical: separate cloud accounts / projects.
- Logical strong: separate databases or schemas with no cross grants.
- Logical weak: shared tables with row filters and policies.
You can combine layers. Enterprise regulated tenants may get physical separation. Long-tail tenants get schema separation plus policies. Explain the blast radius of a mistake at each layer.
Fairness is part of the product
A tenant paying you money expects dashboards during their Black Friday. Another tenant running an unbounded join is not "interesting SQL." It is an availability incident. Quotas, timeouts, and tiered dedicated warehouses are product features, not optional polish.
Cost attribution builds trust
If the platform bill is a blob, finance will eventually kill shared analytics. Per-tenant credits, storage, and anomaly alerts turn the platform into something finance can govern. Mention chargeback early.
What good looks like
You ask about enterprise dedicated needs and residency. You refuse "WHERE tenant_id" as the only control. You describe onboarding templates so security is default, not tribal knowledge.
Internal vs external tenants
If "tenants" are internal business units, political boundaries still matter, but legal risk differs. If tenants are external SaaS customers, a leak is a company-ending event. Ask which world you are in. Your isolation tiering should match the legal reality.
Onboarding and offboarding as design requirements
A platform that takes two weeks of tickets to onboard is not multi-tenant. It is managed hosting. Templated provisioning plus automated offboarding (revoke, delete after retention, catalog cleanup) belongs in the functional design, not in a later ops footnote.
Clarifying residency early
EU customer data pinned to EU regions changes account layout, replication, and support access. If you ignore residency until the end, your pretty pooled warehouse diagram may be illegal for the biggest deal on the pipeline.