Çok kiracılı bir SaaS, tek bir uygulamanın birden fazla müşteriye (kiracıya/tenant) hizmet vermesidir. Her müşteri kendi verisini, kullanıcılarını ve ayarlarını görür, ama hepsi aynı sistemde çalışır. Bu mimariyi sıfırdan kurarken verilen kararlar, ürünün ileride ne kadar rahat ölçekleneceğini belirliyor.

Önce en kritik soru: veri izolasyonu

Bir kiracının verisinin başka bir kiracıya sızması, bir SaaS için en büyük felakettir. Üç temel yaklaşım var:

• Ortak veritabanı, kiracı kimliği ile: Her satırda bir tenantId tutarsınız. En basit ve en ucuz yöntem; ama her sorguda kiracı filtresini asla unutmamak gerekir.
• Şema başına kiracı: Her kiracıya ayrı şema. Daha güçlü izolasyon, daha çok yönetim yükü.
• Veritabanı başına kiracı: En güçlü izolasyon, en yüksek maliyet. Genelde büyük kurumsal müşteriler için.

Çoğu ürün ortak veritabanı + tenantId ile başlar; büyüdükçe gerekirse ayrışır.

Kiracı filtresini merkezi hale getirin

Ortak veritabanı seçtiyseniz en tehlikeli hata, bir sorguda kiracı filtresini unutmaktır. Bunu her geliştiricinin hatırlamasına bırakmayın. Veri erişimini tek bir katmandan geçirin ve kiracı filtresini otomatik ekleyin:

// Her sorgu, aktif kiracıyı otomatik kapsar
function forTenant(tenantId) {
  return {
    find: (q = {}) => db.collection.find({ ...q, tenantId })
    insert: (doc) => db.collection.insertOne({ ...doc, tenantId })
  };
}

Tek bir doğru yer, dağınık yüzlerce filtreden çok daha güvenli.

Kiracıyı isteğin başında çözün

Her istekte "bu kim?" sorusunu en başta cevaplayın: alt alan adı (musteri.uygulama.com), bir başlık veya oturumdaki bilgi. Çözülen kiracıyı isteğin geri kalanına taşıyın ki aşağıdaki katmanlar tekrar uğraşmasın.

Gürültülü komşu sorunu

Aynı sistemi paylaşan kiracılardan biri kaynakları tüketirse, diğerleri yavaşlar, buna "gürültülü komşu" denir. Önlemler:

• Kiracı başına hız sınırı koyun.
• Ağır işleri (rapor, dışa aktarma, toplu e-posta) kuyruğa alın, anında çalıştırmayın.
• Kiracı bazında temel kullanım metrikleri tutun ki kim ne tüketiyor görün.

Özelleştirme ama ortak çekirdek

Müşteriler logo, alan adı, bazı ayarlar ister. Bunları veri olarak modelleyin (kiracı ayarları), kod olarak değil. "Şu müşteri için özel kod" yazmaya başladığınız an, bakım kâbusu başlar. Çekirdek tek kalmalı; farklar yapılandırmadan gelmeli.

Özet

İyi bir multi-tenant SaaS'ın sırrı sürpriz değil: sağlam veri izolasyonu, merkezi kiracı filtresi, isteğin başında kiracı çözümü, gürültülü komşuya karşı sınırlar ve veriyle yapılan özelleştirme. Bu temelleri baştan doğru kurarsanız, ölçeklenme bir kriz değil, bir ayar meselesine dönüşür.