AdvancedSystem-Design
45 min
Design a Multi-Tenant SaaS Platform
Multi-TenancySecurityBillingSRE
Advertisement
Interview Question
Design a SaaS platform with tenant isolation, noisy-neighbor controls, per-tenant config, and usage-based billing.
Key Points to Cover
- Isolation models: shared DB with tenant keys vs siloed DBs
- Per-tenant quotas, rate limits, and resource pools
- Config/feature flags by tenant; migrations and seeding
- Metering, usage pipeline, and billing reconciliation
- Observability and SLOs per tenant; noisy-neighbor detection
Evaluation Rubric
Clear tenant isolation strategy30% weight
Quota/rate limit and fairness plan25% weight
Accurate metering & billing design25% weight
Tenant-level SLOs & observability20% weight
Hints
- 💡Consider tenant routing keys for sharding.
Common Pitfalls to Avoid
- ⚠️**Over-reliance on a single isolation model:** Choosing only shared databases can lead to noisy neighbor issues and security concerns for sensitive tenants. Conversely, only offering siloed databases can be prohibitively expensive for many customers.
- ⚠️**Insufficiently granular usage metering:** Vague or infrequent usage tracking can lead to inaccurate billing and customer dissatisfaction. It's important to track all billable actions.
- ⚠️**Complex and brittle configuration management:** Inconsistent or difficult-to-manage per-tenant configurations can lead to deployment errors and operational overhead.
- ⚠️**Ignoring the cost implications of isolation:** Siloed databases, while offering strong isolation, can significantly increase infrastructure costs and complexity. Proper cost modeling is essential.
- ⚠️**Lack of automated testing for isolation and billing logic:** Thorough automated testing is critical to ensure tenant data remains segregated and billing calculations are accurate.
Potential Follow-up Questions
- ❓How to migrate a tenant between shards?
- ❓How to handle per-tenant encryption keys?
Advertisement