Çok Kiracılı (Multi-Tenant) Mimari

Çok kiracılı mimari, bir uygulamanın tek bir örneğinin — ve tipik olarak tek bir veritabanının — birçok ayrı müşteriye ("kiracılara", ör. farklı şirketlere) hizmet verdiği baskın SaaS altyapı desenidir; her kiracının verisi, fiziksel olarak aynı hesaplama ve depolamayı paylaşsalar bile diğer tüm kiracıların verisinden mantıksal olarak izole tutulur. Bu, her müşterinin tamamen ayrı, özel bir örnek ve veritabanı aldığı tek kiracılı mimarinin tam tersidir. Çok kiracılılık, SaaS'ı ölçekte ekonomik olarak uygulanabilir kılan şeydir: müşteri başına ayrı bir sunucu ve veritabanı sağlamak ve sürdürmek yerine (tek kiracılı), bir satıcı binlerce veya milyonlarca müşteriye eşzamanlı hizmet veren tek bir kod tabanı ve tek bir altyapı seti dağıtır; bu, müşteri başına operasyonel maliyeti çarpıcı biçimde düşürür ve her müşterinin aynı hata düzeltmelerinden ve özellik yayınlarından anında yararlanmasını sağlar. Artan izolasyon (ve maliyet) sırasına göre üç yaygın uygulama stratejisi vardır: (1) her tabloda bir `tenant_id` sütunu bulunan paylaşılan şema, her sorguda uygulama düzeyinde satır düzeyi güvenlik veya ara katman yazılımıyla filtrelenir — en ucuz, erken aşama SaaS için en yaygın olanı; (2) paylaşılan veritabanı, kiracı başına ayrı şema — orta düzey izolasyon, kiracı başına yedekleme/geri yükleme daha kolay; (3) kiracı başına tamamen ayrı veritabanı — en yüksek izolasyon ve katı uyumluluk/veri ikametgahı gereksinimlerini karşılamak için en kolay olanı, ama tek kiracılılığın operasyonel maliyetinin büyük kısmını geri getirir. Çok kiracılı sistemlerdeki en yıkıcı hata sınıfı, bir kiracı izolasyonu hatasıdır — `WHERE tenant_id = ?` filtresi eksik bir sorgu, Kiracı A'nın verisini Kiracı B'ye sızdırır — bu yüzden olgun çok kiracılı SaaS kod tabanları, her uygulama sorgusunun filtreyi hatırlayacağına güvenmek yerine izolasyonu veritabanı veya ORM katmanında zorunlu kılar (ör. Postgres Satır Düzeyi Güvenlik politikaları). Somut örnek: bir proje yönetim SaaS'ı, her tablosunda (`projects`, `tasks`, `comments`) bir `tenant_id` yabancı anahtarı bulunan paylaşılan bir Postgres veritabanı kullanır. Bir Postgres RLS politikası şu şekilde tanımlanır: `CREATE POLICY tenant_isolation ON tasks USING (tenant_id = current_setting('app.tenant_id')::uuid);` — yani bir uygulama katmanı hatası bir sorguda kiracıya göre filtrelemeyi unutsa bile, veritabanının kendisi başka bir kiracıya ait satırları döndürmeyi reddeder; bu da SaaS güvenlik hatalarının en zarar verici kategorisine karşı derinlemesine savunma sağlar. Bazı SaaS ürünleri en büyük veya uyumluluk açısından en hassas müşterileri için hibrit bir "silo" katmanı sunar — aksi halde çok kiracılı bir platform içinde sağlanan tamamen özel bir veritabanı (hatta özel hesaplama kaynağı) — bu, o belirli müşteriye satıcının herkes için varsayılan, maliyet açısından verimli mimarisi olan çok kiracılılığı terk etmesine gerek kalmadan daha güçlü izolasyon garantileri ve daha kolay veri ikametgahı uyumluluğu sağlar.