🏢
Platform & Risk

Multi-Tenant SaaS Application

Isolation Aur Noisy Neighbour
💡 Multi-tenant SaaS EK BADI BUILDING hai jisme kai companies ke office hain. Sawaal ye hai — har company ko poori manzil doge (mehnga, safe) ya ek hall mein partition (sasta, par shor sab tak jaata hai)?

Teen isolation models hain aur trade-off saaf hai. SHARED DATABASE, SHARED SCHEMA (tenant_id column) — sabse sasta, sabse scalable, par data leak ka risk sabse zyada (ek missing WHERE clause = dusre tenant ka data). SCHEMA PER TENANT — beech ka rasta. DATABASE PER TENANT — sabse safe aur enterprise clients isi ki demand karte hain, par hazaaron tenants par operationally bhaari.

Asli production problem NOISY NEIGHBOUR hai — ek bada tenant saare resources kha jaata hai aur baaki sab slow ho jaate hain. Solutions: per-tenant rate limiting aur quotas, aur bade tenants ko dedicated infrastructure par shift karna. Ye batana ki "hum hybrid rakhte hain — chhote tenants shared, bade dedicated" sabse practical jawab hai.

// Shared schema — har query par tenant_id LAZMI
SELECT * FROM orders WHERE tenant_id = :tenant AND id = :id;

// Ek missing tenant_id = data breach. Isliye ise application
// code par mat chhodo — row-level security ya ek mandatory
// repository layer lagao jo tenant_id apne aap inject kare.
🏢
Multi-tenant SaaS EK BADI BUILDING hai jisme kai companies ke office hain. Sawaal ye hai — har company ko poori manzil doge (mehnga, safe) ya ek hall mein partition (sasta, par shor sab tak jaata hai)?
1 / 2
⚡ Quick Recap
  • Teen models: shared schema → schema per tenant → DB per tenant
  • Noisy neighbour ke liye per-tenant quotas aur rate limits
  • Tenant filtering framework level par enforce karo, code discipline par nahi
Is page mein (2 subtopics)

Naya tenant aane par uska schema/database provision karna, default data seed karna, aur routing configure karna — ye sab automated hona chahiye. Manual onboarding hazaaron tenants par possible nahi.

Aur tenant ko ek model se doosre mein MIGRATE karna aana chahiye — chhota tenant bada ho jaaye to shared se dedicated par shift. Isliye tenant ka data hamesha cleanly separable hona chahiye, chaahe wo abhi shared schema mein ho.

💡Tip: Tenant migration ka rasta pehle din se socho. Baad mein shared schema se data nikaalna bahut painful hota hai agar tenant_id har jagah consistent nahi hai.

Enterprise clients custom fields, custom workflows aur custom branding maangte hain. Har tenant ke liye code fork karna disaster hai — configuration-driven approach chahiye.

Custom fields ke liye ya to JSONB column use karo (flexible, par query slow) ya EAV model (queryable, par complex). Feature flags per-tenant rakho taaki features selectively on/off ho sakein bina code branch ke.

// Per-tenant config, code fork nahi
tenant_config: {
  tenant_id, branding, enabled_features[],
  custom_fields: { "priority": "enum[low,high]" },
  limits: { api_qps, storage_gb }
}