Multi-Tenant SaaS Mimarisi Rehberi

Multi-tenant mimari nedir, gerçek soru nedir?

Çok kiracılı (multi-tenant) SaaS, birden çok müşterinin aynı uygulama altyapısını paylaşmasıdır; gerçek mimari soru ise 'paylaşımın nerede bittiği'dir: hangi kaynak ortak, hangi veri nasıl izole? Bu kararın üç boyutu vardır — veri izolasyonu, performans izolasyonu ve operasyon modeli — ve üçü birlikte, hem maliyet yapınızı hem satabileceğiniz müşteri segmentini belirler.

Üç izolasyon modeli: karşılaştırma

Model	İzolasyon	Maliyet	Uygun olduğu yer
Kiracı başına veritabanı	En güçlü; yedekleme/geri yükleme kiracı bazında	En yüksek; bağlantı ve operasyon çarpanı	Kurumsal, regülasyonlu müşteriler; az sayıda büyük kiracı
Ortak DB, kiracı başına şema	Güçlü mantıksal ayrım	Orta; şema yönetimi otomasyon ister	Orta ölçek; yüzlerce kiracı
Ortak şema, satır bazlı (tenant_id)	Uygulama disiplinine bağlı	En düşük; en kolay ölçek	Çok sayıda küçük kiracı; self-servis SaaS

Modeller dışlayıcı değildir: olgun SaaS ürünleri çoğunlukla hibrit çalışır — self-servis segment satır bazlı, kurumsal segment ayrı şema/veritabanı. Mimarinin görevi bu hibritliği baştan mümkün kılmaktır.

Satır bazlı modelde disiplin: tenant_id her sorguda

Ortak şemada güvenliğin tamamı tek kurala iner: hiçbir sorgu tenant filtresi olmadan çalışmaz. Bu kural insana bırakılmaz, altyapıya gömülür: istekten tenant kimliğinin çözülmesi (alt alan adı, başlık veya token claim'i), bağlama taşınması ve veri katmanında otomatik uygulanması — Hibernate filtreleri, Spring AOP veya PostgreSQL'in satır düzeyi güvenliği (RLS) bu otomasyonun araçlarıdır. RLS özellikle değerlidir: filtre veritabanında zorlandığı için uygulama katmanındaki bir unutma, veri sızıntısına dönüşmeden engellenir. Test tarafında 'çapraz kiracı erişim' senaryoları regresyon paketinin kalıcı üyesi olmalıdır.

Performans izolasyonu: gürültülü komşu problemi

Veri izolasyonu yeterli değildir; bir kiracının ağır raporu diğerlerinin isteklerini yavaşlatıyorsa ürününüz fiilen izole değildir. Araç seti: kiracı bazlı hız limiti ve kota; ağır işlerin (rapor, dışa aktarma, toplu içe aktarma) kuyruklara alınıp ayrı işçi havuzlarında koşturulması; kiracı bazlı metrik etiketleme ile 'kim tüketiyor' görünürlüğü; ve büyük kiracıların gerektiğinde ayrı kaynak havuzlarına taşınabilmesi. Fiyatlandırma ile mimari burada buluşur: kota modeliniz, izolasyon modelinizin ticari yüzüdür.

Kiracı yaşam döngüsü: onboarding'den offboarding'e

Çok kiracılı üründe kiracı açılışı bir ekran değil, bir orkestrasyondur: şema/DB oluşturma veya satır alanı ayırma, varsayılan veriler, yetkiler, alan adı/SSO bağlantısı. Aynı ciddiyet kapanışta da gerekir: sözleşme bitiminde verinin dışa aktarılması ve tanımlı süre sonunda silinmesi — KVKK/GDPR'ın saklama ve silme yükümlülükleri kiracı bazında işletilebilir olmalıdır. Bu süreçlerin otomasyonu, satış ekibinin 'yarın açabilir miyiz?' sorusunun cevabıdır.

Sürümleme ve dağıtım: tek kod, çok kiracı

Multi-tenant'ın ekonomisi tek kod tabanından gelir; kiracı özelleştirmeleri yapılandırma ve özellik bayraklarıyla yönetilir, çatallama (fork) ile değil. Veritabanı migrasyonları kiracı sayısıyla çarpılır: şema-bazlı modelde migrasyon orkestrasyonu (sıralı, izlenebilir, geri alınabilir) başlı başına bir yetenektir. Kurumsal müşterilerin 'bize özel sürüm penceresi' talebi, mimaride sürüm halkaları (ring deployment) ile karşılanır — kod çatallamayla değil.

İş etkisi: mimari, satış segmentinizi belirler

Kurumsal alıcıların güvenlik anketlerinde izolasyon modeli açık soru olarak gelir: verimiz nerede, kiminle paylaşımlı, yedeği ayrı mı alınabilir, ülke içinde mi? Satır bazlı ekonomiyle başlayan bir ürün, bu sorulara 'ayrı şema/DB seçeneğimiz var' diyebildiği gün kurumsal segmente satabilir. Tersi de doğrudur: herkese ayrı veritabanı açan bir ürün, self-servis segmentte maliyetle boğulur. İzolasyon stratejisi teknik tercih değil, gelir stratejisidir.

Sık sorulan sorular

Hangi modelle başlamalıyım?

Hedef segmentle: self-servis odaklıysanız satır bazlı + RLS; ilk müşterileriniz kurumsal ise şema bazlı başlangıç güven verir. Her durumda hibrite evrilebilir bir tenant çözümleme katmanı kurun.

tenant_id'yi JWT'ye koymak yeterli mi?

Taşıma için evet; güven için hayır — claim sunucuda doğrulanmalı ve veri katmanında otomatik filtreye bağlanmalıdır. İstemciden gelen hiçbir kiracı bilgisi tek başına yetki kaynağı olamaz.

Kiracı başına şifreleme anahtarı gerekli mi?

Regülasyonlu segmentlerde güçlü bir satış ve güvenlik aracıdır: kiracı bazlı anahtar, offboarding'de 'anahtarı imha et' ile kriptografik silme imkânı verir. Operasyon maliyetiyle birlikte planlanmalıdır.

Gürültülü komşuyu nasıl tespit ederim?

Tüm metrik ve loglara kiracı etiketi ekleyin; kaynak tüketimini kiracı bazında panolayın. Etiket yoksa problem ancak müşteri şikâyetiyle görünür — yani geç.

Multi-tenant kontrol listesi

Hedef segmente göre izolasyon modeli ve hibrit yolu seçildi
Tenant çözümleme merkezî; bağlam tüm katmanlarda taşınıyor
Veri katmanında otomatik tenant filtresi (RLS/Hibernate filter) zorunlu
Çapraz kiracı erişim testleri regresyonda
Kiracı bazlı kota, hız limiti ve metrik etiketleme aktif
Onboarding/offboarding otomasyonu ve silme süreçleri tanımlı
Migrasyon orkestrasyonu ve sürüm halkaları kurulu

SSH Yazılım, çok kiracılı SaaS ürünlerinde izolasyon mimarisi tasarımı ve Spring tabanlı uygulama geliştirme hizmeti verir. Ürününüzün kiracı mimarisini birlikte kuralım.