1. GİRİŞ

Multi‑tenant (çok kiracılı) sistemler, tek bir yazılım örneğinin (application instance) birden fazla müşteri veya kiracı (tenant) tarafından paylaşılarak kullanıldığı mimari yaklaşımı temsil eder. Bulut tabanlı SaaS (Software as a Service) çözümlerinin çoğu multi‑tenant mimariler üzerine kuruludur. Bu yaklaşım, operasyonel maliyetleri düşürürken hızlı provisioning, merkezi güncelleme ve ölçek ekonomisi sağlar. Ancak doğru tasarlanmadığında güvenlik, veri izolasyonu, performans ve uyumluluk sorunları ortaya çıkabilir.

Bu neden bugün önemli?

• SaaS iş modellerinin büyümesiyle tek platformda çok sayıda müşteriyi etkin yönetme ihtiyacı arttı.
• Bulut altyapısındaki otomasyon ve container teknolojileri multi‑tenant çözümleri daha erişilebilir hale getirdi.
• Regülasyonlar (GDPR, PCI‑DSS vb.) ve güvenlik beklentileri tenant isolation stratejilerini kritik kılıyor.

Kimler için önemli?

• SaaS ürün ekipleri ve platform mühendisleri
• Güvenlik, veri yönetişimi ve uyumluluk ekipleri
• Ürün yöneticileri: tenant bazlı pricing, SLAs ve onboarding stratejileri geliştirenler

Hangi problemleri çözüyor?

• Maliyetleri paylaşarak ölçeği büyütme ve yönetilebilir işletim modeli sağlama
• Tek merkezden güncelleme ve dağıtım ile operasyonel verimlilik
• Rapid onboarding ve tenant lifecycle yönetimi (trial, upgrade, deprovision)

2. KAVRAMSAL TEMELLER

2.1 Temel tanımlar

Tenant

Bir uygulama örneğini paylaşan bağımsız müşteri ya da kurum; kullanıcı grubu ve veri kümesi ile temsil edilir.

Tenant Isolation

Farklı tenant'ların verilerinin, kaynaklarının ve performansının birbirinden ayrılması. Isolation hem güvenlik hem de performans boyutlarına sahiptir.

Provisioning

Yeni tenant oluşturma ve yapılandırma süreci; otomasyon ile hızlı ve tekrarlanabilir olmalıdır.

On‑demand scaling

Kiracı taleplerine göre kaynakların dinamik olarak artırılıp azaltılması.

2.2 Çok kiracılı mimari modelleri

Temel olarak üç model yaygındır:

• Isolated (single‑tenant per instance): Her tenant'ın ayrı uygulama veya altyapı örneği vardır. İzolasyon maksimumdur ama maliyet yüksektir.
• Shared application, isolated schema: Uygulama paylaşılır, ancak tenant'lara ait veriler ayrı veritabanı şemalarında tutulur (RDBMS schema per tenant veya DB per tenant).
• Shared schema (row‑level multitenancy): Aynı tablo yapısı içinde tenant_id sütunu ile veriler ayrılır. Maliyet ve operasyonel yönetim avantajı vardır ancak daha zayıf isolation sunar.

2.3 Tasarım trade‑offs

• Güvenlik vs Maliyet: Yüksek izolasyon güvenliği arttırır fakat altyapı maliyetini yükseltir.
• Operasyonel karmaşıklık vs Performans: Çok sayıda DB/şema yönetimi operasyonel yük getirirken row‑level paylaşım yönetimi daha basit görülebilir ama performans sürprizleri ortaya çıkabilir.
• Uyumluluk vs Esneklik: Regülasyon gereksinimi olan tenant'lar için dedicated altyapı gerekebilir.

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ VE AKIŞ

3.1 Sistem mimarisi — high level

Modern multi‑tenant sistemler genelde şu bileşenleri içerir: tenant registry (metadata store), provisioning service, authentication/authorization katmanı, tenant‑aware application layer, data layer (shared/isolated stratejisine göre) ve observability/monitoring. Bir istek geldiğinde uygulama tenant context'i tespit eder (subdomain, JWT claim, header) ve buna göre veri erişimini, konfigürasyonu ve policy'leri uygular.

3.2 Tenant context propagation

Tenant identification kritik bir adımdır. Yaygın yaklaşımlar:

• Subdomain routing: tenantname.example.com ile tenant belirleme.
• JWT / Access token: token içinde tenant_id claim'i taşımak; service çağrılarında token relay etmek.
• Header parametresi: API gateway aracılığıyla tenant header'i set edilip downstream servislere iletilir. Ancak header spoofing güvenlik riski taşıyabilir—gateway doğrulaması önemlidir.

3.3 Data partitioning stratejileri

Veri ayrımı (partitioning) seçimi uygulamanın büyüme, SLAs ve uyumluluk gereksinimlerine göre yapılır:

• Database per tenant: En güçlü izolasyon. Kolay backup/restore, tenant taşıma. Yönetim overhead'i ve connection count artışı dezavantajdır.
• Schema per tenant: Orta seviye izolasyon; aynı DB instance içinde şema ayrıcalığı sağlar. Migrate ve backup operasyonları daha karmaşıktır.
• Shared schema (tenant_id kolonu): En düşük maliyet; kolay shard ve scale. Fakat veri erişim güvenliği, tenant bazlı query optimizasyonu ve delete/retention talepleri daha zorludur.

3.4 Tenant onboarding ve provisioning

Hızlı onboarding için provisioning otomasyonu şarttır. İş akışı tipik olarak: tenant signup → validation → resource allocation (DB, storage, quotas) → initial configuration → notification. Infrastructure as Code ve templating ile provisioning reproducible ve idempotent olmalıdır. Ayrıca tenant lifecycle (trial→paid→suspended→deleted) için otomasyon ve audit kayıtları gereklidir.

3.5 Quota ve resource governance

Tenant başına CPU/RAM, storage, API rate limit, concurrency gibi kaynak kotaları uygulanmalıdır. Bu kotalar hem maliyet tahmini hem de noisy neighbor (gürültülü komşu) olaylarını önlemek için kritik önemdedir. Throttling, circuit breaking ve fair queuing stratejileri kullanın.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Stripe — finansal çok kiracılı örnek

Stripe gibi ödeme platformları, binlerce müşteri ve her birinin farklı uyumluluk gereksinimleri ile çalışır. Yüksek güvenlik, veri izolasyonu ve düzenli audit gereksinimleri nedeniyle bazı tenant'lar için ayrı süreçler ve encryption at rest stratejileri uygulanır. Platform genelde shared codebase ama tenant bazlı configuration ve policy enforcement kullanır.

4.2 Slack — tenant bazlı messaging

Slack gibi iletişim platformları workspace bazlı tenant yönetimi uygular. Veri partitioning ve access control messaging geçmişi, arama endeksi ve dosya depolama için tenant aware olarak tasarlanmıştır. Multiregion replication ve e‑discovery özellikleri kurumsal müşteriler için esastır.

4.3 Shopify — e‑ticaret çok kiracılık

Shopify, milyonlarca mağazaya hizmet verir. Her mağaza tenant olarak ele alınır; bazı mağazalar için özel temalar, uygulamalar ve veritabanı optimizasyonları gerekebilir. Çoklu plan ve plugin ekosistemi tenant bazlı feature flags ve resource quota yönetimini gerekli kılar.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Operasyonel maliyetlerin azalışı: tek uygulama örneği ile birden fazla müşteri hizmet alır.
• Kolay güncelleme ve rollout: tek codebase update ile tüm tenant'lara yeni özellik verilebilir.
• Resource sharing ile daha iyi donanım kullanımı ve ölçek ekonomisi.

Sınırlamalar

• Isolation eksikliği güvenlik risklerine yol açabilir—yanlış konfigürasyon veri sızıntılarına sebep olabilir.
• Performans gürültülü komşular (noisy neighbors) nedeniyle dalgalanabilir.
• Uyumluluk ve veri silme (right to be forgotten) gibi regülasyon talepleri shared schema modellerinde zordur.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• İhtiyaca göre model seçin: startup aşamasında shared schema ekonomik, kurumsal müşteriler için isolated model tercih edilebilir.
• Provisioning otomasyonunu Infrastructure as Code ile gerçekleştirin; idempotent script ve templateler kullanın.
• Tenant lifecycle management: trial, billing, suspend, delete süreçlerini otomatik ve izlenebilir kılın.

Performans ve ölçeklenebilirlik

• Quota ve rate limiting ile noisy neighbor etkilerini sınırlandırın; circuit breakers ve backpressure mekanizmaları uygulayın.
• Data tiering ve arşivleme: aktif verileri sıcak depolarda, eski verileri cold storage'a taşıyın.

Güvenlik ve uyumluluk

• Tenant verilerini en az yetki ilkesine göre erişime açın; encryption at rest ve in transit uygulayın.
• Audit logging ve tenant bazlı erişim kayıtlarını saklayın; regülasyon ihtiyaçlarına göre export ve e‑discovery sağlayın.

Observability

• Tenant bazlı metrikler (latency, error rate, resource usage) toplayın; SLA ihlallerini tenant bazında algılayın.
• Multi‑tenant tracing: trace metadata içine tenant_id ekleyerek sorun tespitini hızlandırın.

8. SIK YAPILAN HATALAR

• Tenant identification'u güvenilmez yöntemlerle yapmak (ör. sadece header) — gateway doğrulaması yoksa header spoofing riski vardır.
• Regülasyon gereksinimlerini baştan değerlendirmemek — GDPR/PCI gereklilikleri mimariyi etkiler.
• Yetersiz testing: tenant bazlı integration testleri ve sis‑test senaryoları ihmal edilmemeli.
• Backup/restore ve tenant deletion süreçlerini basitleştirilmiş şekilde uygulamak — veri kalıntıları veya geri dönüşsüz silmeler risklidir.

9. GELECEK TRENDLER

1. Federated multi‑tenant platformlar: Tenant'ların veri residency ve uyumluluk gereksinimlerine göre federated control plane ile yönetim.
2. AI‑assisted tenant management: Anomali tespiti, cost‑optimization önerileri ve kapasite planlama için ML modelleri kullanılacak.
3. Serverless multitenancy: Function‑level tenant isolation ve per‑tenant cold start optimizasyonları artacak.
4. Privacy‑aware storage: Selective redaction, tokenization ve privacy hooks tenant‑specific veri işlemleri için native destek sağlayacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Hangi çok kiracılı model benim için doğru?

   Karar, müşteri profiline bağlıdır: küçük/orta ölçekli SaaS için shared schema maliyet/operasyon dengesi sağlar; kurumsal ve regüle sektörler için isolated DB/instance tercih edilir.

2. 2. Tenant verilerini nasıl güvenle silerim?

   Silme işlemlerinde immutable backup retention, secure delete ve audit log'ları kullanın. Shared schema'da fiziksel silme karmaşıktır; soft delete + scheduled purge stratejilerini değerlendirin.

3. 3. Tenant başına SLA nasıl yönetilir?

   Tenant bazlı metrikler ve alert'ler kurun; premium tenant'lara ayrılmış kaynak veya priority queuing sağlayın.

4. 4. Noisy neighbor etkisini nasıl azaltırım?

   Kaynak kotaları, rate limiting, per‑tenant request queues ve autoscaling kuralları ile izolasyonu güçlendirin.

5. 5. Çok kiracılı sistemlerde encryption nasıl uygulanmalı?

   Hem transit hem rest için encryption zorunlu olmalı; tenant‑specific encryption keys (KMS) ve key rotation politikaları uygulayın.

6. 6. Tenant migration (region change) nasıl yapılır?

   Veri replikasyonu, consistent cutover planı ve dual‑write/dual‑read stratejileri ile orchestrated migration uygulayın; downtime'ı minimize etmek için canary migration kullanın.

7. 7. Shared schema'da performance tuning önerileri nelerdir?

   Tenant_id bazlı indeksleme, partitioning, materialized views ve per‑tenant caching kullanın; heavy reporters için separate reporting replicas oluşturun.

8. 8. Tenant bazlı logging maliyeti nasıl kontrol edilir?

   Sampling, retention policies ve cold archive ile log maliyetlerini minimize edin; kritik event'leri long‑term saklarken debug log'larını kısa süreli tutun.

Anahtar Kavramlar

Tenant Isolation

Kiracıların verilerinin, yapılandırmasının ve performansının birbirinden ayrılması.

Provisioning

Yeni tenant oluşturma süreci: otomasyon, konfigürasyon ve resource allocation.

Noisy Neighbor

Bir tenant'ın aşırı kaynak tüketimi diğer tenant'ların performansını bozması.

Quota

Tenant başına kaynak sınırları: CPU, memory, storage, API rate.

Data Partitioning

Veriyi tenantlara göre ayırma stratejisi: db per tenant, schema per tenant veya shared schema.

Öğrenme Yol Haritası

1. 0–1 ay: Multi‑tenant temel kavramlarını öğrenin; farklı partitioning stratejilerinin artı/eksi durumlarını inceleyin.
2. 1–3 ay: Küçük bir SaaS uygulamasını shared schema ile implement edin; provisioning ve tenant lifecycle senaryolarını otomatikleştirin.
3. 3–6 ay: Isolated DB/instance modelini, backup/restore, tenant migration ve uyumluluk senaryolarını uygulayın; performans testleri yapın.
4. 6–12 ay: Multi‑region, federated control plane ve cost governance; production‑grade observability ve security pratikleri üzerinde deneyim kazanın.