SaaS Web Uygulamalarında Multi-Tenancy: Tek Uygulamayla Yüzlerce Müşteriyi Aynı Anda Nasıl Sunarsın?

SaaS fikrin var, belki ilk on müşteriyi bile bağladın – sonra biri sorar: "Bunu kendi logomuzla, kendi subdomain'imizden alabilir miyiz?" İkincisi formdaki alanların farklı olmasını ister. Üçüncüsü "verimiz gerçekten diğerlerinden ayrı mı duruyor?" diye sorar.

Tam o noktada anlarsın: Artık ürün değil, Multi-Tenancy SaaS mimarisi inşa ediyorsun. Ve şimdi vereceğin kararları iki yıl sonra ancak büyük acılarla geri alabilirsin. Hannover'dan yıllardır çok kiracılı (multi-tenant) web uygulamaları geliştiriyoruz ve hep aynı hataların ileride nasıl pahalı migrasyonlara dönüştüğünü görüyoruz.

Multi-Tenancy SaaS gerçekten ne anlama gelir?

Multi-Tenancy şudur: Tek kod tabanı, tek çalışan uygulama, birden çok birbirinden ayrılmış müşteri. Her tenant – şirket, ekip ya da bireysel kullanıcı – yalnızca kendi verisini, kendi markasını ve sadece ödediği özellikleri görür.

Bunun karşıtı Single-Tenancy'dir: Her müşteriye ayrı kurulum, ayrı veritabanı, ayrı sunucu. Klasik özel yazılım yaklaşımıdır ve bakım yükü açısından SaaS iş modelinin sonu demektir.

Bu yüzden Multi-Tenancy bir özellik değil, temel bir karardır. Şunları belirler:

• 10 mu yoksa 10.000 müşteriye mi hizmet verebilirsin (ekibini patlatmadan)
• Yeni özellikleri ne kadar hızlı yayına alabilirsin (tek kod tabanı = tek deploy)
• Ay sonu bulut faturan gerçekte ne kadar tutar
• KVKK ve GDPR denetimlerinde ne kadar sağlam durursun

İç kullanıma yönelik bir web uygulaması ile gerçek bir SaaS arasındaki farkı henüz tam ayırt edemiyorsan, önce Web Uygulama Geliştirme Rehberi'mizi okumanı öneriyoruz – Multi-Tenancy tam o sınırdır.

Üç Multi-Tenancy modeli: Shared DB, Separate Schema, Separate DB

Tenant verilerini teknik olarak ayırmanın üç yerleşik yolu var. Hiçbiri "objektif olarak doğru" değil – ama ikisi senin somut projen için büyük olasılıkla yanlış. İşte dürüst karşılaştırma.

Model 1: Shared Database, Shared Schema (tenant_id sütunuyla)

Tüm müşteriler tek veritabanı ve tek tablo yapısını paylaşır. Her tablodaki her satırda bir tenant_id sütunu vardır, her sorgu buna göre filtre uygular.

SELECT * FROM invoices WHERE tenant_id = $1 AND status = 'unpaid';

Avantajlar:

• En ucuz çözüm (tek DB, tek backup, tek index)
• En kolay migrasyon (tek ALTER TABLE ile herkes güncellenir)
• Çok sayıda küçük müşteri için ideal (1.000+ abonelik hesabı)

Dezavantajlar:

• Programlama hatasında tenant veri sızıntısı riski en yüksek
• "Gürültülü komşu" etkisi (tek büyük müşteri herkesi yavaşlatır)
• Bireysel backup/restore zor ("geçen haftaki verimizi geri yükler misiniz?")

Model 2: Shared Database, Separate Schema

Tek veritabanı, ama her müşteriye özel şema (PostgreSQL'de: tenant_a.invoices, tenant_b.invoices). Uygulama her istekte şemayı değiştirir.

Avantajlar:

• DB seviyesinde mantıksal ayrım (müşteri başına backup mümkün)
• Şema migrasyonları müşteri bazında yayınlanabilir (kademeli güncelleme)
• Orta ölçekli müşteri sayısında iyi denge (10–500 müşteri)

Dezavantajlar:

• Tüm müşterileri kapsayan migrasyonlar düzgün bir migration tool ister
• PostgreSQL connection pool'ları daha karmaşık hale gelir
• Saf Shared'a göre bakım yükü daha fazla

Model 3: Müşteri başına ayrı veritabanı (Separate Database)

Her tenant kendi fiziksel (veya en azından mantıksal olarak tamamen ayrılmış) veritabanını alır.

Avantajlar:

• Maksimum veri izolasyonu (DB seviyesinde sert kilit)
• Bireysel performans SLA'ları mümkün
• Compliance avantajı: KVKK, GDPR ve ISO 27001 denetimlerinde anlatması kolay

Dezavantajlar:

• En yüksek altyapı maliyeti
• 200 DB'ye şema migrasyonu başlı başına bir görev
• Olgun bir araç seti şart (provisioning, monitoring, backup)

Veri izolasyonu pazarlık konusu değildir – tek sızıntı SaaS'ı bitirir

Hangi modeli seçersen seç: Müşteri A, müşteri B'nin verisini görüyorsa SaaS'ın bitmiştir. "Zorda" değil – bitmiştir. Kimse bir daha sana ödeme yapmaz, kimse bir daha veri yüklemez ve ilk denetimde para cezası girdabına girersin.

Tenant sızıntılarının en yaygın sebebi sunucunun hacklenmesi değil, tek bir sorguda unutulmuş bir WHERE tenant_id = ? ifadesidir. Tek seferlik unutmak yeterli.

İzolasyonu gerçekten su sızdırmaz hale getirmenin yolları:

1. Row-Level Security (RLS) veritabanı seviyesinde aktif olsun (PostgreSQL native destekler). DB'nin kendisi, kod hata yapsa bile yabancı veriyi vermez
2. ORM ara katmanı ile global tenant filtresi (Prisma middleware, TypeORM subscriber gibi) – atlanması imkansız olmalı
3. Audit logging: Tenant'lar arası okuma yapan admin fonksiyonları açıkça işaretlenmeli ve loglanmalı
4. Penetration test: En az yılda bir, hedef açıkça "Tenant A'dan Tenant B verisine ulaşmayı dene" olmalı

Subdomain routing: kunde1.deinsaas.de teknik olarak nasıl çalışır?

B2B SaaS'ta tenant başına markalama olmazsa olmaz. Kimse çalışanlarına "neden mygenericsaas.com/login?company=acme adresinden giriyoruz?" diye açıklamak istemez. Bu yüzden standart yaklaşım tenant subdomain'leridir: acme.deinsaas.de, kunde2.deinsaas.de.

Üç adımda çalışır:

Adım 1: Wildcard DNS

Bir DNS kaydı eklersin: *.deinsaas.de → sunucu IP. Böylece tüm subdomain'ler otomatik olarak sunucuna yönlenir. Cloudflare, Vercel veya Netlify'da tek tıkla halledilir. Önemli: TLS sertifikan da wildcard destekli olmalı (Let's Encrypt DNS-Challenge ile bunu çözer).

Adım 2: Subdomain'i server middleware'de oku

Nuxt 3'te (Next.js'te de aynı şekilde) subdomain'i render başlamadan server middleware'de okursun:

// server/middleware/tenant.ts (Nuxt 3)
export default defineEventHandler(async (event) => {
  const host = getRequestHeader(event, 'host') || ''
  const subdomain = host.split('.')[0]

  if (subdomain === 'www' || subdomain === 'app') return

  const tenant = await db.tenant.findUnique({ where: { slug: subdomain } })
  if (!tenant) throw createError({ statusCode: 404, statusMessage: 'Tenant not found' })

  event.context.tenant = tenant
})

event.context.tenant artık her API rotasında, her server bileşeninde ve her useAsyncData çağrısında elinin altında – tamamen sunucu tarafında, hiçbir client kodu işin içine girmez.

Adım 3: Markalamayı ve temayı dinamik yükle

Tenant nesnesi logo URL'sini, primary color'ı ve fontu içerir. Layout'ta okur, CSS custom property'lerine yazarsın ve müşterinin markasıyla render edersin. UX tarafıyla derinleşmek isteyen Web uygulamalarında UX tasarımı yazımıza bakabilir.

Fiyat planları ve feature flag'ler: Tarifeleri teknik olarak doğru kurmak

Free, Starter, Business, Enterprise – her SaaS'ın tarife seviyeleri vardır. Kritik soru: Free kullanıcı tarayıcı devtools'undan Enterprise özelliğini açamasın diye ne yapıyorsun?

Cevap: Server-side feature flag'ler – asla yalnızca frontend'de değil.

Plan tabanlı feature flag'ler

Her tenant'ın DB'de bir plan değeri olsun. Korunan her özellik kontrol etsin:

function canAccess(tenant: Tenant, feature: string): boolean {
  return PLAN_MATRIX[tenant.plan].includes(feature)
}

Eşleştirme basit bir sabit. Her route'a hardcode etme.

Limit tabanlı flag'ler

Bazı özellikler binary değil, limit içerir ("Starter'da maks. 5 proje"). Bu limitler yazma işleminden önce çağrılan merkezi bir enforceLimit() fonksiyonunda olmalı – frontend'de gizlenmiş kalmamalı.

Feature flag araçlarıyla A/B test

Deneysel flag'ler için (plan değil, "yüzde 10 müşteriye aç") Unleash, PostHog veya GrowthBook öneriyoruz – self-hosted veya managed. Önemli olan: Flag çözünürlüğü server-side ve tenant başına olmalı, kullanıcı başına değil – aynı müşterinin farklı çalışanları farklı özellikler görmesin.

Mevcut sistem bu noktada duvara çarpmışsa (eski Excel çözümleri, hardcoded PHP switch'ler), genelde Strangler Fig yöntemiyle eski sistemleri değiştirmek doğru yoldur.

KVKK ve GDPR: Multi-Tenant SaaS'ta veri sözleşmesi, ayrım ve silme

Türkiye'de KVKK, Avrupa'da GDPR – kurumsal veya orta ölçekli müşteriye satış yapmak istiyorsan compliance olmadan kapı bile açılmaz. Hannover'da her büyük tedarikçi sunumunda görüyoruz: Önce uyumluluk, sonra özellik.

En önemli yükümlülükler:

Müşteri başına Veri İşleme Sözleşmesi (DPA / AVV)

Müşterilerin, son kullanıcılarının kişisel verilerini senin üzerinden işlettiği için sen GDPR/KVKK anlamında veri işleyensin. Her müşteriyle imzalı bir sözleşmen olmalı. En iyi yaklaşım: DPA modülünü onboarding'e entegre et – dijital imza yoksa giriş yok.

Teknik olarak ispatlanabilir veri izolasyonu

Denetimde "tenant_id sütunumuz var" demek yetmez. Şunları gösterebilmelisin:

• Hangi teknik önlemler tenant'lar arası erişimi engelliyor (RLS, middleware, testler)
• Hangi organizasyonel önlemler çalışan erişimini düzenliyor (DB operasyonlarında dört göz prensibi)
• Yedeklerin nasıl izole olduğu (Tenant A backup'ı restore edilirken Tenant B'yi etkilememeli)

Silme süreci ve unutulma hakkı

Bir son kullanıcı (müşterinin değil, çalışanı) silme talep ederse:

1. Hangi tenant'ta olduğunu tespit etmelisin
2. Tamamen silmelisin (yedeklerde de, saklama süresine göre)
3. İşlemi belgeli olarak müşteriye geri bildirmelisin

Silme sürecini ilk müşteriden önce planla – sonradan 50 tenant DB'sinden "gerçekten" silmek tam bir kabus.

Veri İşleme Envanteri (VVT / VERBIS)

Avrupa'da 250+ çalışanı olan firmalar için zorunlu, Türkiye'de KVKK kapsamında VERBİS kaydı – pratikte hep gerekli. Envanterin tüm tenant veri akışlarını dokümante etmeli.

Ölçeklenme ve mimaride ileriye bakış

Multi-Tenancy son nokta değil, başlangıçtır. İlk 100 müşteri akmaya başlayınca bölgesel veri ikametgahı (AB müşterileri Frankfurt'ta, ABD müşterileri Virginia'da), yatay DB ölçekleme ve tenant bazlı cache gibi konular gelir. Erkenden ölçeklenebilir web mimarisinin gelecek sigortasına nasıl katkı sağladığını bilmek, gerekli vidaları en başta yerleştirmeni sağlar.

Custom code mu, hazır araç mı sorusu da yeniden gündeme gelir: Bubble veya Retool gibi düşük-kod araçları çoğunlukla zayıf tenant izolasyonu sunar. Detaylı karşılaştırma için Custom Code vs. Hazır Webapp Çözümleri yazımız var.

Sonuç: Multi-Tenancy SaaS bir mimari karardır, programlama egzersizi değil

Multi-Tenancy SaaS'ı doğru kuran üç şey kazanır: Ölçek, kâr marjı ve compliance. Yanlış kuran tam o sırayla kaybeder: Önce performans, sonra güven, sonra kontrat.

Kısa özet:

• Shared Database + tenant_id ve Row-Level Security ile başla – yüksek hassas sektör verisi yoksa
• Subdomain routing'i frontend hack'i değil server middleware olarak planla
• Feature flag'leri server-side kur, sadece CSS class olarak değil
• KVKK ve GDPR'yi ilk günden uygula, "ilk büyük müşteri sorunca" değil
• Mimariyi yeterince basit tut ki ekibin iki yıl sonra hala içinde gezinebilsin

Hannover'da SaaS web uygulamalarını tam bu Multi-Tenancy ilkeleri üzerine kuruyoruz – mimari kararından ilk ödeme yapan tenant'a kadar yanındayız.

Cagri Ersöz

SaaS'ın için Multi-Tenancy Mimari Workshop'u

SaaS planlıyorsun ya da onuncu müşteride ölçek sorunlarına takıldın mı? 2 saatlik bir workshop'ta modelini analiz ediyor, veri izolasyonundaki riskleri gösteriyor ve KVKK/GDPR setup'ı dahil somut bir mimari öneri sunuyoruz.

Mimari Workshop al