SaaS Mimarisi: Çok Kiracılı (Multi-Tenant), Güvenli ve Ölçeklenebilir Sistemler

SaaS ürünlerinin çoğu çok kiracılıdır (multi-tenant): tek bir sistem, birbirinden bağımsız birçok müşteriye (tenant) hizmet verir. Bu model ekonomiktir ama bir mühendislik disiplini gerektirir; çünkü tek bir izolasyon hatası, bir müşterinin verisini başka bir müşteriye gösterebilir. Bu yazıda multi-tenant bir SaaS’ı güvenli ve ölçeklenebilir kurmanın temel kararlarını ele alıyoruz.

Tenant izolasyonu neden her şeyin merkezinde?

Multi-tenant bir sistemde en büyük risk teknik bir çökme değil, veri sızmasıdır: A müşterisinin B müşterisinin verisini görmesi. Bu, hem KVKK/GDPR açısından ciddi bir ihlal hem de güvenin anında kaybı demektir. Bu yüzden izolasyon, sonradan eklenen bir özellik değil, mimarinin temel taşı olmalıdır.

Altın kural: her sorgu, her istek ve her arka plan işi bir tenant bağlamı taşımalı ve bu bağlam otomatik olarak zorlanmalıdır. İzolasyonu geliştiricinin “unutmamasına” bırakmak, er ya da geç başarısız olur.

Veritabanı stratejileri

Tenant verisini ayırmanın üç temel yolu vardır; her birinin dengesi farklıdır.

1. Paylaşımlı veritabanı, paylaşımlı şema (tenant_id)

Tüm tenant’lar aynı tablolarda, her satırda bir `tenant_id` ile ayrışır. En ekonomik ve en kolay ölçeklenen yaklaşımdır; çoğu SaaS burada başlar. Riski: izolasyon tamamen uygulama katmanına bağlıdır. Bunu güçlendirmek için veritabanı seviyesinde satır düzeyi güvenlik (row-level security) ve merkezî bir sorgu katmanı kullanın; “WHERE tenant_id” koşulunu tekil sorgulara bırakmayın.

2. Paylaşımlı veritabanı, ayrı şema

Her tenant kendi şemasında. Daha güçlü mantıksal izolasyon sağlar ama tenant sayısı arttıkça göç (migration) yönetimi zorlaşır. Orta ölçekli, görece az sayıda büyük müşterisi olan ürünlere uyar.

3. Ayrı veritabanı (tenant başına)

En güçlü izolasyon, en yüksek maliyet ve operasyonel yük. Genellikle düzenleyici zorunluluğu olan veya çok büyük kurumsal müşteriler için tercih edilir. Çoğu KOBİ-hedefli SaaS için gereğinden ağırdır.

Pragmatik öneri: Paylaşımlı şema + tenant_id ile başlayın, izolasyonu veritabanı seviyesinde de zorlayın. Kurumsal bir müşteri “kendi veritabanım olsun” dediğinde, mimariniz o tekil tenant’ı ayırmaya izin verecek şekilde tasarlanmış olsun.

İş yükü ve kuyruklar

Kullanıcının beklediği istek (HTTP) hızlı olmalı; ağır işler (rapor üretimi, e-posta/bildirim gönderimi, yapay zeka çağrıları, toplu içe aktarma) senkron yapılmamalıdır. Bunları bir kuyruğa alıp arka planda işleyin.

• Kuyruk, ani yük artışlarını (spike) tamponlar; sistem çökmek yerine sıraya alır.
• Bir tenant’ın ağır işi, diğerlerinin deneyimini bozmamalı — adil kuyruklama veya tenant başına hız sınırı düşünün.
• Başarısız işler için yeniden deneme ve “ölü mektup” (dead-letter) stratejisi tanımlayın; sessizce kaybolan iş, en sinsi hatadır.

Gözlemlenebilirlik: tenant farkındalığı

Multi-tenant bir sistemde “sistem yavaş” yeterli bir bilgi değildir; “hangi tenant için yavaş?” sorusuna cevap verebilmelisiniz. Bu yüzden log, metrik ve izlerinizi (trace) tenant kimliğiyle etiketleyin.

• Her log satırı ve metrik bir tenant boyutu taşısın (ama PII taşımasın — bkz. KVKK kontrol listesi).
• Tenant başına kullanım (istek, depolama, yapay zeka token’ı) ölçülsün; hem faturalama hem kapasite planlaması buna dayanır.
• Alarmları anlamlı kurun: bir tenant’ın anormal davranışı tüm sistemi etkilemeden fark edilmeli.

Maliyet: kiracı başına düşünün

Toplam altyapı maliyetiniz düşse bile, asıl soru şudur: bir tenant bize ne kadara mal oluyor? Bunu ölçmeden fiyatlandırma yapmak, kârlı görünen ama aslında zarar ettiren müşterilere yol açar. Depolama, hesaplama ve (varsa) yapay zeka çağrılarını tenant başına izleyin. Yapay zeka maliyetini düşürmenin yolları için işletmeler için yapay zeka entegrasyonu yazısındaki model seçimi ve prompt caching bölümüne bakın.

Ölçeklenmeden önce sağlam temel

1. İzolasyonu mimarinin merkezine koyun; her katmanda zorlayın.
2. Paylaşımlı şema + tenant_id ile başlayın, ama tekil müşteriyi ayırmaya açık tasarlayın.
3. Ağır işleri kuyruğa alın; yeniden deneme ve dead-letter tanımlayın.
4. Log/metrik/iz’i tenant’a etiketleyin, PII taşımayın.
5. Maliyeti ve kullanımı kiracı başına ölçün.

Özet

İyi bir multi-tenant SaaS, “çalışan” bir sistemden fazlasıdır; her katmanda izolasyonu garanti eden, ağır işi kuyruğa alan, tenant farkında gözlemlenebilirliğe sahip ve maliyeti kiracı başına bilen bir sistemdir. Bu temeli erken kurarsanız, büyüme bir kriz değil, planlı bir mühendislik süreci olur.