Çoklu Kiracılı (Multi-Tenant) Veritabanı Tasarım Modelleri

Bir SaaS uygulamasında ilk birkaç müşteriyle çalışırken veritabanı tasarımı oldukça sade görünebilir. Fakat tenant sayısı arttığında veri izolasyonu, performans, yedekleme, taşıma, yetkilendirme ve operasyon maliyeti aynı anda önem kazanmaya başlar. Çoklu Kiracılı (Multi-Tenant) Veritabanı Tasarım Modelleri konusu tam olarak bu noktada kritik hale gelir, çünkü yanlış seçilen bir model ilerleyen dönemde hem güvenlik riskini hem de geliştirme maliyetini büyütebilir. On yılı aşkın backend ve veritabanı projelerinde gördüğüm ortak nokta, doğru multi-tenant mimarinin yalnızca hangi tabloda tenant_id tutulacağına karar vermekten çok daha geniş olduğudur. Bu rehberde multi-tenant veritabanı mimarisi nasıl tasarlanır, shared database shared schema ve database per tenant karşılaştırması nasıl yapılır, SaaS uygulamalarında tenant isolation ve row level security nasıl uygulanır ve çoklu kiracılı veritabanlarında ölçeklenebilirlik performans ve veri izolasyonu nasıl birlikte yönetilir sorularını sistematik biçimde ele alacağız.

Multi-Tenant Veritabanı Nedir?

Multi-tenant veritabanı, aynı yazılım platformunu kullanan birden fazla müşteri veya organizasyona ait verilerin ortak ya da kontrollü biçimde ayrılmış veri altyapısında saklandığı tasarım yaklaşımıdır. Buradaki temel konu yalnızca verilerin aynı sunucuda bulunması değildir; her tenant'ın yalnızca kendi verisine erişebilmesi ve diğer tenant'ların iş yükünden mümkün olduğunca az etkilenmesi gerekir. İyi tasarlanmış bir sistem tenant kimliğini authentication, authorization, repository, cache ve background job katmanlarında tutarlı biçimde taşır. Aynı SaaS içinde farklı müşteri segmentlerinin farklı izolasyon seviyelerine sahip olması da mümkündür. Bu nedenle multi-tenancy bir tablo tasarımından çok, uçtan uca sistem sınırı olarak ele alınmalıdır.

Tenant Nedir?

Tenant, SaaS uygulaması içinde kendine ait kullanıcıları, verileri, ayarları ve çoğu zaman faturalandırma ilişkisi bulunan mantıksal müşteri birimidir. Tenant bir şirket, ekip, kurum, mağaza, klinik veya ayrı bir çalışma alanı olabilir. Aynı fiziksel veritabanını kullansa bile tenant verisi başka tenant'lardan erişim ve yetki açısından ayrılmalıdır. Tenant kavramını kullanıcı kavramıyla karıştırmak ciddi modelleme sorunlarına yol açabilir, çünkü tek kullanıcı birden fazla tenant'a üye olabilir. Bu nedenle tenant kimliği sistem içinde ayrı bir first-class entity olarak tasarlanmalı ve tüm ilişkiler bu sahiplik modeline göre kurulmalıdır.

Multi-Tenancy Nedir?

Multi-tenancy, tek bir yazılım sisteminin birden fazla tenant'a hizmet verirken veri, erişim ve kaynak sınırlarını kontrollü biçimde yönetmesi yaklaşımıdır. Tenant'lar aynı application deployment'ını, veritabanını veya altyapı katmanlarını paylaşabilir. Paylaşım maliyet avantajı sağlar, fakat izolasyon sorumluluğunu uygulama ve veritabanı tasarımına taşır. Sistemin hangi katmanlarının ortak, hangilerinin tenant'a özel olacağı açıkça belirlenmelidir. Veritabanı modeli, cache anahtarları, queue mesajları, dosya depolama yapısı ve monitoring etiketleri aynı tenancy mantığıyla uyumlu olmadığında cross-tenant veri sızıntısı riski ortaya çıkabilir.

Single-Tenant ve Multi-Tenant Arasındaki Fark

Single-tenant sistemde her müşteri için ayrı uygulama, veritabanı veya altyapı kümesi bulunabilir. Bu yaklaşım güçlü izolasyon sağlayabilir fakat deployment, bakım ve maliyet tarafında ölçek sorunları oluşturabilir. Multi-tenant sistemde kaynaklar daha fazla paylaşılır ve birim müşteri maliyeti düşürülebilir. Buna karşılık tenant context'in yanlış yönetilmesi çok daha ciddi güvenlik sonuçları doğurabilir. Hangi modelin daha uygun olduğu müşteri sayısı, compliance gereksinimi, operasyon ekibi, veri hacmi ve tenant başına özelleştirme ihtiyacı gibi faktörlere göre değerlendirilmelidir.

Kullanıcı ile Tenant Arasındaki Fark

Kullanıcı bireysel kimliği temsil ederken tenant organizasyonel veri ve yetki sınırını temsil eder. Bir kullanıcı aynı anda birden fazla tenant'a üye olabilir ve her tenant içinde farklı role sahip olabilir. Bu nedenle kullanıcı kaydına doğrudan tek bir tenant_id eklemek bazı SaaS modellerinde ileride kısıtlayıcı hale gelir. Membership tablosu kullanıcı ile tenant arasındaki ilişkiyi daha esnek biçimde modeller. Authentication kullanıcıyı doğrularken tenant membership ve authorization katmanları kullanıcının seçilen tenant içinde hangi işlemleri yapabileceğini ayrıca kontrol etmelidir.

Organization, Workspace ve Tenant Kavramları

Organization ve workspace kavramları ürün deneyiminde farklı anlamlar taşısa da teknik tarafta çoğu zaman tenant sınırının farklı seviyelerini temsil eder. Bazı ürünlerde organization faturalandırma sınırı, workspace ise veri çalışma alanı olabilir. Böyle bir yapıda tüm workspace'ler aynı organization'a bağlı olsa bile ayrı tenant scope gerektirebilir. Model seçilirken iş kavramlarının veritabanındaki izolasyon ihtiyacıyla birebir aynı olduğu varsayılmamalıdır. Önce hangi verinin hangi sınırda görünür olması gerektiği tanımlanmalı, ardından organization, workspace ve tenant ilişkileri bu erişim kurallarına göre modellenmelidir.

SaaS Sistemlerinde Multi-Tenancy Neden Kullanılır?

Multi-tenancy SaaS işletmelerine ortak altyapı üzerinde çok sayıda müşteriye hizmet verebilme avantajı sağlar. Veritabanı, cache, uygulama sunucuları ve operasyon süreçleri paylaşıldığı için tenant başına maliyet düşürülebilir. Merkezi deployment sayesinde güvenlik güncellemeleri ve yeni özellikler tüm müşterilere daha hızlı ulaştırılabilir. Bununla birlikte paylaşım yalnızca maliyet avantajı için yapılmamalı, izolasyon ve performans sınırları baştan tasarlanmalıdır. Özellikle hızlı büyüme hedefleyen SaaS sistemlerinde doğru multi-tenant temel, ileride tenant sayısı arttığında mimarinin tamamen yeniden yazılma ihtiyacını azaltır.

Multi-Tenant Veritabanı Tasarımında Temel Problem Nedir?

Multi-tenant veritabanı tasarımındaki temel problem, mümkün olduğunca verimli kaynak paylaşımı sağlarken tenant verilerinin ve iş yüklerinin güvenli biçimde ayrılmasıdır. Çok güçlü fiziksel izolasyon maliyeti artırabilir, aşırı paylaşım ise güvenlik ve performans riskini büyütebilir. Bu nedenle tasarım aslında izolasyon, maliyet, ölçeklenebilirlik ve operasyon arasında denge kurma problemidir. Enterprise tenant ile küçük bir free-tier tenant'ın aynı storage modeline zorlanması her zaman doğru olmayabilir. Sağlıklı yaklaşım farklı tenant segmentlerinin ihtiyaçlarını ölçmek ve gerektiğinde hibrit bir izolasyon spektrumu kullanmaktır.

Tenant Verilerinin İzolasyonu

Tenant izolasyonu bir tenant'a ait verinin başka tenant tarafından okunamaması, değiştirilememesi veya silinememesi anlamına gelir. Uygulama seviyesinde tenant_id filtresi önemli olsa da tek güvenlik katmanı olarak kullanılması risklidir. PostgreSQL Row-Level Security, composite foreign key ve tenant-aware unique constraint gibi database kontrolleri ikinci savunma katmanı sağlar. Cache, object storage ve background job sistemleri de aynı izolasyon ilkesine göre tasarlanmalıdır. En iyi yaklaşım cross-tenant erişimi normal kod yolunda mümkün olduğunca zor hale getirmektir.

Maliyet

Her tenant için ayrı database güçlü izolasyon sağlasa da database sayısı, connection pool ve bakım ihtiyacı arttıkça maliyet yükselir. Shared schema modeli ise çok sayıda küçük tenant'ın aynı kaynakları verimli paylaşmasına imkan verir. Maliyet yalnızca compute ve storage değildir; migration, backup, support ve monitoring yükü de toplam maliyetin parçasıdır. Büyük tenant'ların küçük tenant'larla aynı pool içinde bulunması kaynak tüketimini dengesiz hale getirebilir. Bu nedenle tenant bazlı cost attribution sistemi hangi segmentin hangi izolasyon modelini ekonomik olarak taşıyabildiğini anlamaya yardımcı olur.

Ölçeklenebilirlik

Ölçeklenebilirlik tenant ve veri sayısı büyüdüğünde sistemin kabul edilebilir performansla çalışmaya devam edebilmesidir. Shared schema başlangıçta yüksek tenant yoğunluğu için verimli olabilir fakat en büyük tenant boyutu büyüdükçe indeks ve noisy neighbor sorunları ortaya çıkabilir. Database-per-tenant yatay dağıtımı kolaylaştırabilir, fakat connection ve operasyon sayısını büyütür. Sharding tenant'ları farklı database kümelerine dağıtarak orta yol sağlayabilir. Bu nedenle ölçek planı yalnızca ortalama tenant'a göre değil, en büyük ve en hızlı büyüyen tenant senaryosuna göre yapılmalıdır.

Performans

Multi-tenant sistemde performans değerlendirilirken global ortalama yerine tenant bazlı latency ve kaynak tüketimi ölçülmelidir. Bir tenant'ın ağır rapor sorgusu diğer tenant'ların p95 ve p99 latency değerlerini yükseltebilir. Tenant-first indeksleme, query timeout, workload queue ve rate limiting bu etkiyi azaltmaya yardımcı olur. Büyük tenant'ı dedicated database veya ayrı shard'a taşımak da etkili bir seçenek olabilir. Performans tasarımı uygulama yayınlandıktan sonra eklenen bir optimizasyon değil, tenancy modelinin temel seçim kriterlerinden biri olmalıdır.

Operasyonel Karmaşıklık

İzolasyon arttıkça yönetilecek database, schema, credential ve migration sayısı da artabilir. Schema-per-tenant modelinde yüzlerce schema'ya migration fan-out yapılması gerekirken database-per-tenant modelinde binlerce connection endpoint yönetilebilir. Bu nedenle daha güçlü izolasyon otomasyon olmadan operasyon ekibini zorlayabilir. Provisioning, migration, backup, monitoring ve offboarding süreçleri kodlanabilir workflow haline getirilmelidir. Doğru model yalnızca teknik olarak güvenli değil, mevcut ekip tarafından sürdürülebilir biçimde işletilebilir olmalıdır.

Compliance

Bazı müşteriler veri yerleşimi, ayrı encryption key, tenant bazlı restore veya dedicated database gibi özel gereksinimlere sahip olabilir. Böyle durumlarda yalnızca shared schema üzerinden ilerlemek ürün satışını sınırlayabilir. Compliance gereksinimleri tenant directory içinde isolation tier, region ve key policy metadata'sıyla modellenebilir. Regüle tenant'lar dedicated region veya dedicated database'e yönlendirilebilir. Bu yaklaşım tüm müşterilere pahalı izolasyon sunmak yerine ihtiyaç duyulan müşterilere kontrollü ve ölçülebilir bir izolasyon seviyesi sağlamayı mümkün kılar.

Tenant Bazında Özelleştirme

Bazı SaaS ürünlerinde tenant bazında farklı feature, workflow veya veri alanları gerekebilir. Schema-per-tenant yaklaşımı fiziksel özelleştirme sunuyor gibi görünse de tenant başına schema farklarının artması migration yönetimini çok zorlaştırabilir. Çoğu durumda ortak schema üzerinde metadata, extension table veya JSONB gibi esnek alanlar daha sürdürülebilir olabilir. Gerçekten farklı data model gerektiren enterprise tenant'lar için dedicated storage düşünülebilir. Özelleştirme ihtiyacı tenancy modelini belirlerken ürün stratejisiyle birlikte değerlendirilmelidir.

Multi-Tenant Database Tasarım Modelleri Nelerdir?

Multi-tenant database tasarımında en yaygın modeller shared database shared schema, shared database separate schema, database per tenant, hybrid ve sharded yapılardır. Modellerin her biri farklı izolasyon, maliyet ve operasyon dengesi sunar. Shared schema çok sayıda küçük tenant için verimli olabilirken database-per-tenant enterprise gereksinimleri için daha güçlü sınırlar sağlar. Hybrid yaklaşım farklı tenant segmentlerinin aynı üründe farklı storage tier kullanmasına imkan verir. Model seçimi yapılırken yalnızca bugünkü tenant sayısı değil, gelecekteki migration ve tenant promotion ihtiyacı da dikkate alınmalıdır.

Shared Database + Shared Schema

Bu modelde tüm tenant'lar aynı database ve aynı tabloları kullanır. Tenant'a ait satırlar çoğunlukla tenant_id kolonu ile ayrılır. Operasyon maliyeti düşüktür ve binlerce küçük tenant aynı schema üzerinde çalışabilir. Buna karşılık yanlış veya eksik tenant filtresi ciddi cross-tenant veri sızıntısına yol açabilir. PostgreSQL RLS, tenant-aware constraints ve otomatik isolation testleri kullanıldığında shared schema hem ekonomik hem de güçlü bir çözüm haline gelebilir.

Shared Database + Separate Schema

Schema-per-tenant modelinde tek database içinde her tenant için ayrı schema oluşturulur. Tenant tabloları fiziksel olarak ayrı namespace içinde bulunur ve search_path veya schema-qualified query ile erişilir. Shared schema'ya göre daha belirgin ayrım sunar. Fakat tenant sayısı yüzlerce veya binlerce olduğunda migration fan-out ve schema version yönetimi önemli operasyon yükü oluşturur. Bu model orta sayıda tenant bulunan ve belirli seviyede fiziksel ayrım isteyen B2B projelerde değerlendirilebilir.

Database Per Tenant

Database-per-tenant yaklaşımında her tenant'ın uygulama verisi ayrı database içinde tutulur. İzolasyon sınırı en belirgin modellerden biridir ve tenant bazında backup, restore ve region seçimi kolaylaşabilir. Buna karşılık connection pool sayısı, provisioning ve migration orkestrasyonu daha fazla otomasyon gerektirir. Tenant directory hangi tenant'ın hangi database endpoint'inde olduğunu takip etmelidir. Az sayıda büyük veya regülasyon gereksinimi yüksek enterprise tenant için oldukça güçlü bir seçenektir.

Hybrid / Tiered Model

Hybrid model aynı SaaS içinde birden fazla tenancy modelini birlikte kullanır. Örneğin free ve standard tenant'lar shared database kullanırken enterprise müşteriler dedicated database'e taşınabilir. Böylece tüm sisteme en pahalı izolasyon seviyesini uygulamak gerekmez. Application business logic storage modelinden ayrıldığı için tenant directory doğru database veya schema'ya routing yapabilir. Başlangıçtan itibaren bu migration yolu düşünülürse büyük müşteriyi shared pool'dan dedicated storage'a taşımak çok daha kontrollü hale gelir.

Sharded Multi-Tenant Model

Sharded model tenant'ları birden fazla database veya cluster arasında dağıtır. Her shard kendi içinde shared schema kullanabilir ve belirli tenant gruplarını barındırabilir. Tenant directory tenant ile shard arasındaki eşleşmeyi tutar. Shard kapasitesi dolduğunda tenant rebalancing yapılabilir veya büyük tenant ayrı shard'a taşınabilir. Bu yaklaşım shared schema'nın verimliliğini korurken tek database sınırının aşılmasına yardımcı olur.

Pool, Bridge ve Silo Modelleri

Pool, bridge ve silo kavramları multi-tenant storage modellerini izolasyon spektrumu üzerinde açıklamanın pratik yollarından biridir. Pool model en fazla paylaşımı, silo model en güçlü fiziksel ayrımı temsil eder. Bridge ise ortak database içinde ayrı schema gibi ara modelleri ifade edebilir. Gerçek SaaS ürünleri çoğu zaman yalnızca tek noktada kalmak zorunda değildir. Tenant segmentlerine göre aynı sistemde pool, bridge ve silo seçeneklerini birlikte sunmak hem maliyet hem enterprise satış ihtiyaçları açısından daha esnek bir yapı sağlayabilir.

Pool Model

Pool modelde birçok tenant aynı database ve aynı tabloları paylaşır. Satırlar tenant kimliğiyle scope edilir ve kaynak kullanımı ortak havuzdan sağlanır. Çok sayıda küçük tenant için yüksek verimlilik sağlar. İzolasyon ağırlıklı olarak logical kontroller, RLS ve application scoping ile korunur. Pool model seçildiğinde noisy neighbor, per-tenant monitoring ve cross-tenant leak testleri mimarinin zorunlu parçaları haline gelmelidir.

Bridge Model

Bridge model genellikle shared infrastructure ile daha belirgin tenant ayrımını birleştirir. Schema-per-tenant buna iyi bir örnektir, çünkü database ortaktır fakat tenant tabloları farklı namespace içinde bulunur. Bu model shared schema'dan daha fazla izolasyon hissi verir. Buna karşılık migration ve schema lifecycle maliyeti daha yüksektir. Tenant sayısı orta seviyede olduğunda ve operasyon ekibi güçlü migration automation kurabildiğinde bridge yaklaşımı mantıklı olabilir.

Silo Model

Silo model tenant başına ayrı database veya ayrı altyapı sınırı kullanır. Bir tenant'ın workload'u diğerlerinden daha kolay ayrılır ve backup, restore veya region politikası tenant bazında uygulanabilir. Bu model enterprise ve regüle müşteriler için güçlü değer sunabilir. Ancak her tenant için connection, migration ve credential yönetimi gerektiğinden otomasyon ihtiyacı yüksektir. Silo yaklaşımı seçilirken izolasyonun ürün fiyatlandırmasında karşılığının bulunması işletme maliyetinin sürdürülebilirliği açısından önemlidir.

İzolasyon Spektrumu

İzolasyon ikili bir karar değildir ve farklı katmanlarda farklı seviyeler uygulanabilir. Uygulama server'ı ortak olurken database dedicated olabilir veya database shared kalırken encryption key tenant'a özel tutulabilir. Bu nedenle mimari değerlendirme yalnızca shared veya dedicated şeklinde yapılmamalıdır. Compute, database, cache, storage ve encryption ayrı ayrı incelenmelidir. Isolation tier kavramı bu seçimleri ürün ve operasyon tarafında daha anlaşılır hale getirir.

Aynı SaaS İçinde Birden Fazla Model Kullanmak

Aynı SaaS içinde farklı tenant segmentlerini farklı storage modellerine yerleştirmek çoğu büyüyen ürün için doğal bir evrimdir. Küçük müşteriler pool içinde çalışırken yüksek trafik veya compliance gereksinimi olan müşteriler dedicated database'e taşınabilir. Bunun mümkün olması için tenant directory ve dynamic routing baştan tasarlanmalıdır. Business service doğrudan sabit database bağlantısına bağımlı olmamalıdır. Böylece isolation tier ürün özelliğine dönüşebilir ve storage migration tüm sistemi yeniden yazmayı gerektirmez.

Model 1: Shared Database + Shared Schema

Shared database ve shared schema modeli SaaS projelerinde başlangıç için en verimli seçeneklerden biridir. Tüm tenant verileri aynı tablo setinde bulunur ve tenant sahipliği satır seviyesinde tutulur. Bu yapı provisioning ve migration işlerini sadeleştirir, çünkü her yeni tenant için yeni database veya schema oluşturmak gerekmez. Buna karşılık tenant isolation'ı uygulama geliştiricisinin her sorguda doğru filtreyi yazmasına bırakmak ciddi risk yaratır. Shared schema kullanıldığında merkezi tenant context, repository scope, PostgreSQL RLS ve tenant-aware constraint yaklaşımını birlikte kullanmak çok daha güvenli sonuç verir.

Shared Schema Nasıl Çalışır?

Shared schema yaklaşımında örneğin projects, invoices ve orders tabloları tüm tenant'ların satırlarını aynı yapıda tutar. Her tenant-scoped satır hangi tenant'a ait olduğunu gösteren tenant_id değeri taşır. Uygulama sorguları aktif tenant context'e göre filtrelenir. Global veriler ise tenant'a bağlı olmayan ayrı tablolarda tutulabilir. Bu model basit görünse de constraint, index ve foreign key tasarımı tenant sınırını database seviyesinde destekleyecek biçimde yapılmalıdır.

tenant_id Kolonu

tenant_id shared schema modelinin temel sahiplik alanıdır. Tenant'a ait her kritik entity'nin bu değeri doğrudan veya güvenilir ilişki üzerinden taşıması gerekir. Sorgular genellikle tenant_id üzerinden scope edildiği için indeks tasarımında önemli role sahiptir. Değer request body'den güvenilerek alınmamalı, authentication ve membership doğrulamasından sonra server tarafında belirlenmelidir. Tenant kimliği yalnızca filtreleme alanı değil, authorization, audit ve observability bağlamının da temel parçası olmalıdır.

Tenant-Scoped Tables

Tenant-scoped table belirli tenant'a ait iş verilerini tutar. Projeler, faturalar, görevler ve müşteri kayıtları çoğu SaaS'ta bu kategoriye girer. Bu tabloların her satırı tenant ownership bilgisine sahip olmalıdır. Foreign key ve unique constraint'ler de aynı tenant içinde ilişki kurulmasını sağlayacak şekilde tasarlanmalıdır. Uygulama query layer tenant-scoped tabloları normal şartlarda tenant filtresi olmadan sorgulatmamalıdır.

Global Tables

Global table tüm tenant'lar tarafından ortak kullanılan verileri tutar. Ülke listesi, para birimi veya platform-level feature tanımları buna örnek olabilir. Bu tablolarda tenant_id bulunması gerekli değildir. Ancak global ve tenant-specific verinin aynı tabloda karıştırılması authorization mantığını zorlaştırabilir. Veri gerçekten global ise model bunu açıkça ifade etmeli, tenant'a özel override gerekiyorsa ayrı bir ilişki veya override tablosu tasarlanmalıdır.

Shared Lookup Tables

Shared lookup table aynı değer setini tüm tenant'lar için ortak sunar. Bu yaklaşım duplicate seed data miktarını azaltır ve migration sürecini sadeleştirir. Tenant bazında farklı lookup değeri gerekirse aynı tabloya doğrudan karışık semantics eklemek yerine scoped extension düşünülebilir. Lookup verilerinin read-only veya admin-managed olması güvenlik modelini basitleştirir. Cache kullanılıyorsa global lookup cache anahtarları tenant-scoped cache anahtarlarından açık biçimde ayrılmalıdır.

Shared Schema Avantajları

Shared schema yeni tenant provisioning'i çok hızlı hale getirir, çünkü çoğu durumda yalnızca tenant ve membership kayıtları oluşturulur. Migration yalnızca tek schema üzerinde çalıştırılır ve tüm tenant'lar aynı schema version kullanır. Connection pooling verimli olur ve binlerce küçük tenant aynı database kaynaklarını paylaşabilir. Cross-tenant internal analytics de teknik olarak daha kolaydır. Bu avantajlar özellikle erken aşama ve yüksek tenant sayısı hedefleyen SaaS ürünlerinde shared schema'yı güçlü bir başlangıç noktası yapar.

Shared Schema Dezavantajları

En büyük risk cross-tenant data leak ihtimalidir. Eksik tenant filtresi veya yanlış cache key başka müşterinin verisinin görünmesine yol açabilir. Büyük tenant noisy neighbor etkisiyle diğer tenant'ların performansını düşürebilir. Tenant bazında backup ve restore işlemleri database-per-tenant modeline göre daha fazla tooling gerektirir. Bu nedenle shared schema düşük operasyon maliyeti sağlasa da güvenlik testleri ve tenant-aware veri modeli konusunda yüksek disiplin ister.

Hangi SaaS Uygulamaları İçin Uygundur?

Çok sayıda küçük veya orta tenant bulunan, veri modeli büyük ölçüde ortak olan SaaS ürünleri için oldukça uygundur. CRM, proje yönetimi, randevu, görev veya B2B yönetim platformları bu modele uyabilir. Tenant başına çok büyük veri hacmi veya sert fiziksel izolasyon gereksinimi varsa başka model daha uygun olabilir. Shared schema seçilirken ileride büyük tenant'ı dedicated database'e taşıma ihtimali göz önünde bulundurulmalıdır. Tenant-aware repository ve tenant directory tasarımı bu gelecekteki migration yolunu açık tutar.

Shared Schema Veri Modeli Nasıl Tasarlanır?

Shared schema veri modelinde yalnızca tablolara tenant_id eklemek yeterli değildir. Tenant sahipliği, user membership, unique constraint ve foreign key ilişkileri birlikte tasarlanmalıdır. Hangi tablonun global, hangisinin tenant-scoped olduğu schema seviyesinde açık biçimde anlaşılmalıdır. Özellikle child tablolar üzerinden cross-tenant ilişki kurulmasını önlemek database constraint'leriyle desteklenebilir. Veri modeline baştan tenant sınırı yerleştirildiğinde application bug'larının veri sızıntısına dönüşme ihtimali önemli ölçüde azaltılabilir.

tenants Tablosu

tenants tablosu sistemdeki her müşteri veya organizasyonun temel kaydını tutar. Tenant adı, state, subscription tier, region ve isolation tier gibi metadata burada bulunabilir. Bu tablo data plane routing kararlarında doğrudan kullanılacaksa sık erişilen alanların ayrı control plane cache'inde tutulması düşünülebilir. Tenant lifecycle state'i provisioning, active ve offboarding gibi süreçlerin kontrolünü kolaylaştırır. Tenant kaydı yalnızca kullanıcıya gösterilen isim değil, tüm platformun isolation ve routing kararlarının merkezidir.

users Tablosu

users tablosu platform kimliklerini temsil eder. Kullanıcı tek tenant'a ait olmak zorunda değilse tenant_id doğrudan users tablosuna koymak yerine membership ilişkisi kullanmak daha esnektir. Authentication bilgileri kullanıcı seviyesinde tutulabilir. Tenant-specific role veya profile bilgisi membership veya ayrı tenant-user tablosunda saklanabilir. Bu tasarım aynı kullanıcının birden fazla organization arasında geçiş yapmasını destekler.

Tenant Membership

Membership tablosu kullanıcı ile tenant arasındaki üyeliği modeller. user_id, tenant_id, role ve membership state gibi alanlar içerebilir. Composite unique constraint aynı kullanıcının aynı tenant'a iki kez üye olmasını engelleyebilir. Authentication sonrasında aktif tenant seçildiğinde membership kaydı doğrulanmalıdır. Tenant context sadece URL'den veya request header'dan geldi diye kullanıcıya doğrudan güven verilmemelidir.

Tenant-Scoped Entity

Tenant-scoped entity her kaydın belirli tenant'a ait olduğu tabloyu ifade eder. projects veya orders gibi tablolarda tenant_id açıkça bulunmalıdır. İndeksler tenant-first tasarlanabilir ve RLS policy bu alana göre filtreleme yapabilir. Child ilişkilerde tenant ID'nin korunması cross-tenant foreign key riskini azaltır. Veri modeli geliştiriciye hangi entity'nin tenant sınırında olduğunu açıkça göstermelidir.

Global Entity

Global entity platformun tüm tenant'ları için ortak olan kayıttır. Para birimleri, ülkeler veya platform-level configuration örnek verilebilir. Bu tablolar tenant-scoped security policy'ye tabi olmayabilir. Ancak global tabloya tenant-specific override yazılmaya başlandığında semantics karışabilir. Böyle durumlarda global base data ile tenant override data ayrı tablolar halinde modellenmelidir.

tenant_id Her Tabloda Olmalı mı?

Hayır, gerçekten global olan tablolarda tenant_id bulunması gerekli değildir. Fakat tenant verisi taşıyan tablolarda tenant sahipliğinin dolaylı ilişkiler üzerinden kaybolması sorgu ve güvenlik tasarımını zorlaştırabilir. Özellikle yüksek riskli entity'lerde tenant_id değerini child tabloda tekrar taşımak composite foreign key ve index açısından faydalı olabilir. Duplicate görünse bile bu alan isolation constraint için değer sağlar. Her tablo için “bu satır hangi tenant'a ait?” sorusunun açık bir cevabı bulunmalıdır.

Tenant Sahipliği Nasıl Modellenmeli?

Tenant ownership mümkün olduğunca explicit ve database tarafından doğrulanabilir biçimde modellenmelidir. Bir resource doğrudan tenant'a aitse tenant_id foreign key kullanmak en açık çözümdür. Child entity'lerde parent ile aynı tenant'a ait olma şartı composite key ile zorlanabilir. Application service yine authorization kontrolü yapmalıdır. Database ownership modeli ile application permission modeli ayrı fakat birbirini tamamlayan katmanlar olarak düşünülmelidir.

Tenant ID Tasarımı

Tenant ID veri modelinin her katmanında kullanılacağı için erken verilmesi gereken önemli kararlardan biridir. Integer, UUID ve ULID gibi farklı seçenekler performans, güvenlik ve developer experience açısından farklı özellikler sunar. Public identifier ile internal database identifier'ı ayırmak çoğu sistemde yararlı olabilir. Hangi format seçilirse seçilsin tenant ID'nin gizli veya tahmin edilemez olmasının authorization yerine geçmeyeceği unutulmamalıdır. Tenant erişimi her zaman doğrulanmış kullanıcı kimliği ve membership ilişkisine dayanmalıdır.

Integer Tenant ID

Integer tenant ID küçük indeks boyutu ve hızlı join davranışı açısından oldukça verimlidir. Sequence tabanlı üretim de basittir. Bununla birlikte ID değerleri tahmin edilebilir olduğu için public URL'de kullanıldığında tenant sayısı hakkında bilgi verebilir. Bu durum tek başına güvenlik açığı olmamalıdır, çünkü authorization ID gizliliğine dayanmamalıdır. İstenirse internal integer ID ile public UUID birlikte kullanılabilir.

UUID

UUID dağıtık sistemlerde merkezi sequence olmadan benzersiz identifier üretmeyi kolaylaştırır. Public identifier olarak tahmin edilmesi integer'a göre daha zordur. Buna karşılık index boyutu ve yazma locality davranışı database performansını etkileyebilir. Modern UUID varyantları sıralanabilirlik açısından daha iyi seçenekler sunabilir. Tenant sayısı ve sorgu pattern'i dikkate alınarak benchmark yapmak doğru karar vermeyi kolaylaştırır.

ULID

ULID zaman sıralı ve okunabilir karakter yapısına sahip identifier yaklaşımı sunar. UUID'ye benzer global uniqueness avantajı sağlarken indeks locality açısından daha düzenli davranabilir. Public tenant ID için kullanılabilir. Fakat uygulama ve database kütüphanelerinin ULID desteği kontrol edilmelidir. Format seçimi isolation güvenliği sağlamadığı için membership ve authorization kontrolleri yine zorunludur.

Public Tenant ID ve Internal Tenant ID

Public ve internal identifier'ı ayırmak esnek bir tasarım sağlar. Database join'lerinde küçük integer ID kullanılırken API ve URL'lerde UUID veya slug gösterilebilir. Public identifier değişse bile internal ilişkiler sabit kalabilir. Bu yaklaşım data export ve migration sırasında mapping gerektirebilir. Tenant directory her iki identifier arasındaki ilişkiyi güvenilir biçimde tutmalıdır.

Tenant ID Tahmin Edilebilir Olmalı mı?

Tenant ID'nin tahmin edilebilir olmaması küçük bir ek koruma sağlar fakat temel güvenlik mekanizması değildir. Bir saldırgan başka tenant'ın ID değerini biliyor olsa bile erişememelidir. IDOR testleri tam olarak bu davranışı doğrular. Uygulama resource ID ve tenant ID kombinasyonunu authorization kontrolünden geçirmelidir. Gizli identifier'a güvenerek tenant isolation tasarlamak ileride ciddi güvenlik hatalarına yol açabilir.

Tenant ID'yi URL'de Kullanmak

Tenant veya organization slug'ını URL'de göstermek kullanıcı deneyimi açısından faydalı olabilir. Örneğin tenant-specific subdomain veya path active tenant seçimini kolaylaştırır. Ancak URL değeri yalnızca tenant talebini ifade eder, yetki kanıtı değildir. Server kullanıcı membership'ini ayrıca doğrulamalıdır. URL'den gelen tenant bilgisi trusted tenant context'e dönüştürülmeden repository sorgularına gönderilmemelidir.

Tenant ID'yi Güvenlik Mekanizması Olarak Görmemek

Tenant ID'nin UUID olması başka tenant'a erişimi otomatik olarak engellemez. Client değeri değiştirerek başka tenant ID gönderebilir. Güvenlik authenticated identity, membership, authorization ve database isolation katmanlarıyla sağlanmalıdır. Identifier yalnızca hangi tenant üzerinde işlem yapılacağını belirtir. Cross-tenant güvenlik testlerinde doğru resource ID ile yanlış tenant kombinasyonları özellikle denenmelidir.

Tenant Context Nasıl Belirlenir?

Tenant context her request'in hangi tenant adına çalıştığını belirleyen güvenilir sistem bilgisidir. Subdomain, custom domain, JWT claim, session, API key veya kullanıcı tarafından seçilen active organization bu context'in kaynağı olabilir. Ancak gelen ham değer doğrudan trusted kabul edilmemelidir. Authentication identity ile tenant membership doğrulandıktan sonra server-side tenant context oluşturulmalıdır. Bu context service, repository, database connection, audit ve background job katmanlarına kontrollü biçimde taşınmalıdır.

Subdomain

tenant.example.com biçimindeki subdomain tenant seçimi için yaygın bir yöntemdir. DNS ve routing katmanı request'i doğru SaaS uygulamasına yönlendirir. Server subdomain değerini tenant directory üzerinden gerçek tenant kaydına çözer. Kullanıcının bu tenant'a üyeliği ayrıca kontrol edilir. Subdomain yalnızca routing sinyalidir ve tek başına authorization sağlamaz.

Custom Domain

Enterprise müşteriler kendi domain'lerini SaaS tenant'ına bağlamak isteyebilir. Custom domain tenant directory içinde tenant ID ile eşleştirilmelidir. Domain ownership doğrulaması provisioning sürecinin parçası olmalıdır. Request geldiğinde host bilgisi üzerinden tenant çözülür ve user membership kontrol edilir. Domain mapping cache kullanıyorsa offboarding ve domain değişikliklerinde doğru invalidation uygulanmalıdır.

JWT

JWT içinde tenant veya organization claim taşınabilir. Bu yaklaşım API request'lerinde tenant context çözümünü hızlandırabilir. Claim yalnızca güvenilir issuer tarafından imzalanmış ve doğrulanmış token'dan okunmalıdır. Kullanıcının tenant üyeliği token lifetime boyunca değişebileceği için uzun süreli token'larda revocation veya membership refresh ihtiyacı dikkate alınmalıdır. Çok tenant üyesi kullanıcılar için active tenant claim'i session seçimiyle birlikte tasarlanabilir.

Session

Web uygulamalarında active tenant session içinde saklanabilir. Kullanıcı organization değiştirdiğinde session tenant context güncellenir. Her değişiklikte membership doğrulaması yapılmalıdır. Session ID güvenli cookie veya server-side session store ile yönetilebilir. Tenant context'in eski session state nedeniyle yanlış tenant'ta kalmaması için organization switch testleri önemlidir.

API Key

B2B entegrasyonlarında API key doğrudan belirli tenant veya service account ile ilişkilendirilebilir. Bu durumda key lookup sonucu trusted tenant context üretilebilir. API key'in tenant ID'yi ayrıca request body'den göndermesine gerek kalmayabilir. Key rotation ve revocation tenant lifecycle ile birlikte yönetilmelidir. Audit log hangi key'in hangi tenant adına işlem yaptığını açıkça göstermelidir.

Request Header

Özel tenant header active organization seçimi için kullanılabilir. Ancak client tarafından gönderildiği için header değeri tek başına güvenilir değildir. Server authenticated user veya API key ile header tenant arasında membership veya access ilişkisini doğrulamalıdır. Doğrulama sonrası header değeri trusted context'e dönüştürülebilir. Internal service çağrılarında imzalı service identity ve tenant propagation kuralları ayrıca tanımlanmalıdır.

Kullanıcının Aktif Organization'ı

Bir kullanıcının birden fazla organization üyeliği varsa aktif tenant seçimi ürün deneyiminin doğal parçasıdır. Kullanıcı UI üzerinden organization seçebilir ve server membership doğrulaması yapar. Aktif seçim session veya kısa ömürlü token claim'ine yazılabilir. Repository katmanı yalnızca doğrulanmış active tenant ID ile çalışmalıdır. Organization switch sonrası cache ve open transaction state'lerinin eski tenant context taşımadığı test edilmelidir.

Güvenilir Tenant Context Kaynağı

Trusted tenant context server tarafından doğrulanmış kimlik ve membership ilişkisine dayanmalıdır. Client'ın gönderdiği raw tenant değeri doğrudan database filtrelerine aktarılmamalıdır. Middleware authentication sonrası tenant resolution yapabilir ve immutable request context oluşturabilir. Service ve repository katmanları bu context'i dependency olarak alabilir. Bu yaklaşım tenant isolation mantığını her endpoint developer'ının tekrar yazmasına olan ihtiyacı azaltır.

Tenant ID Neden Request Body'den Alınmamalıdır?

Request body tamamen client kontrolündedir ve kullanıcı başka bir tenant ID gönderebilir. Server bu değeri trusted kabul ederse IDOR veya cross-tenant write riski doğar. Güvenli yaklaşım tenant context'i authenticated identity, API key, session veya doğrulanmış membership üzerinden server tarafında çözmektir. Request body yalnızca business data taşımalıdır. Tenant sahipliği server tarafından eklenmeli ve database policy ile ayrıca doğrulanmalıdır.

Client-Controlled Tenant ID Riski

Client'ın tenant_id alanını değiştirebilmesi başka tenant adına kayıt oluşturma veya veri okuma girişimine imkan verebilir. Frontend UI alanı gizli olsa bile HTTP request manuel olarak değiştirilebilir. Server tarafı hiçbir zaman UI davranışına güvenmemelidir. Resource ownership trusted tenant context üzerinden belirlenmelidir. Cross-tenant integration tests request body'ye farklı tenant ID vererek bu riski düzenli olarak doğrulamalıdır.

Authentication Identity

Authentication kullanıcının veya service account'un kim olduğunu doğrular. Tenant access kararı bu identity üzerinden membership veya API credential ilişkisiyle verilir. Client'ın gönderdiği tenant değeri ancak bu ilişki doğrulandıktan sonra kullanılabilir. Authentication ile tenant isolation aynı şey değildir fakat birbirini tamamlar. Anonymous veya eksik doğrulanmış request'ler tenant-scoped repository katmanına ulaşmamalıdır.

Session'dan Tenant Çözmek

Web uygulamasında active tenant session state içinde tutulabilir. Session oluşturulurken ve tenant switch yapılırken membership doğrulanır. Sonraki request'lerde server-side session trusted context kaynağı olur. Client yine tenant path gönderebilir fakat session ile eşleşmiyorsa request reddedilebilir veya yeniden doğrulama yapılabilir. Bu yaklaşım request body'nin tenant ownership üzerinde kontrol sahibi olmasını engeller.

Membership Doğrulaması

Membership kontrolü authenticated user'ın seçilen tenant içinde gerçekten erişim hakkı olup olmadığını doğrular. Üyelik suspended veya revoked durumda olabilir. Sadece membership varlığı değil state ve role bilgisi de değerlendirilmelidir. Kullanıcı tenant değiştirirken bu kontrol tekrar yapılmalıdır. Sonuç trusted tenant context ve authorization permission set'ine dönüştürülebilir.

Middleware ile Tenant Context

Middleware tenant resolution mantığını endpoint kodundan merkezi bir katmana taşır. Authentication sonucu, host, token veya header bilgisi birlikte değerlendirilir. Membership doğrulandıktan sonra request context içine immutable tenant bilgisi eklenir. Service layer bu bilgiyi request body yerine context'ten alır. Böylece developer'ın yanlış tenant kaynağı kullanma ihtimali azalır.

Authorization ile Tenant Isolation Ayrımı

Tenant isolation “hangi tenant'ın verisine erişebilirsin?” sorusunu, authorization ise “o tenant içinde ne yapabilirsin?” sorusunu yanıtlar. Kullanıcı doğru tenant'a üye olsa bile invoice silme yetkisi olmayabilir. Bu nedenle membership doğrulaması ile RBAC veya permission kontrolü ayrı aşamalardır. Database RLS tenant sınırını korurken application authorization daha ayrıntılı permission kararları verir. İki katmanı birbirine karıştırmamak güvenlik modelini daha anlaşılır hale getirir.

Tenant Context Uçtan Uca Nasıl Taşınır?

Tenant context HTTP request'ten başlayarak authentication, service, repository, database ve audit katmanlarına kaybolmadan taşınmalıdır. Her katmanın tenant ID'yi yeniden client girdisinden çözmeye çalışması tutarsızlık yaratır. Merkezi context object request'in yaşam süresi boyunca güvenilir kaynak olarak kullanılabilir. Background job veya event üretildiğinde context ayrıca message envelope içine trusted metadata olarak yazılmalıdır. Böylece synchronous ve asynchronous işlemler aynı tenant isolation kuralına göre çalışır.

HTTP Request

HTTP request subdomain, token veya API key gibi tenant resolution sinyalleri taşır. Bu değerlerin hiçbiri doğrulama yapılmadan trusted kabul edilmemelidir. Request girişinde correlation ID ve authentication metadata da oluşturulabilir. Tenant resolution sonucu request context'e eklenir. Ham tenant input ile trusted tenant ID loglarda açıkça ayrılabilir.

Authentication Middleware

Authentication middleware kullanıcı veya service identity'yi doğrular. Token signature, session veya API key geçerliliği bu aşamada kontrol edilir. Başarılı identity tenant resolver'a girdi olur. Authentication başarısızsa tenant data layer'a erişim verilmemelidir. Middleware aynı zamanda audit için actor ID üretir.

Tenant Resolver

Tenant resolver host, active organization veya credential metadata'sını gerçek tenant kaydına eşler. Kullanıcının membership durumu kontrol edilir. Sonuç tenant ID, isolation tier ve gerekirse region bilgisi içerebilir. Resolver mümkün olduğunca merkezi tutulmalıdır. Tenant directory cache kullanıyorsa state değişiklikleri güvenli biçimde invalidate edilmelidir.

Service Layer

Service layer business operation'ı trusted tenant context altında çalıştırır. Method signature tenant context veya scoped dependency alabilir. Client payload içindeki tenant alanı business karar için kullanılmamalıdır. Authorization permission checks bu katmanda uygulanabilir. Service layer database modelinin shared veya dedicated olduğunu bilmek zorunda kalmayacak şekilde tasarlanabilir.

Repository Layer

Repository tenant scoping'i query seviyesinde zorunlu hale getirir. Shared schema'da her query tenant predicate içerir veya ORM global scope kullanır. Database-per-tenant modelinde repository doğru connection resolver üzerinden çalışır. Cross-tenant admin sorguları normal repository API'sinden ayrılmalıdır. Bu sınır hatalı query'nin tenant isolation'ı aşmasını zorlaştırır.

Database Connection

Database connection aktif tenant context'i özellikle RLS veya schema selection için taşıyabilir. Shared PostgreSQL RLS modelinde transaction içinde SET LOCAL ile tenant değeri belirlenebilir. Connection pool kullanıldığında state'in sonraki request'e sızmaması gerekir. Dedicated database modelinde tenant directory doğru endpoint ve credential'ı seçer. Her durumda connection state reset ve transaction boundary testleri yapılmalıdır.

Audit Log

Audit log actor, tenant, action ve resource bilgisini birlikte kaydetmelidir. Cross-tenant support veya admin işlemleri ayrıca işaretlenmelidir. Tenant ID audit kaydının temel boyutlarından biri olmalıdır. Logların kendisi de hassas veri içermemelidir. Incident incelemesinde hangi kullanıcının hangi tenant context ile işlem yaptığını görebilmek büyük önem taşır.

Response

Response yalnızca aktif tenant scope içindeki verileri içermelidir. Serialization öncesinde başka tenant satırlarının query sonucuna girmediği garanti edilmelidir. Cache katmanı tenant-aware key kullanmalıdır. Error response gereksiz tenant metadata sızdırmamalıdır. Cross-tenant resource ID talebinde “var ama erişimin yok” gibi bilgi sızıntısı oluşturabilecek davranışlar güvenlik modeline göre dikkatle ele alınmalıdır.

Repository Layer ile Tenant Scoping

Repository layer tenant isolation'ı developer alışkanlığına bırakmamak için güçlü bir kontrol noktasıdır. Normal application code tenant-scoped repository API'leri üzerinden çalışmalı ve tenant filtresi otomatik eklenmelidir. Global veya cross-tenant query ihtiyacı ayrı ve daha yüksek yetkili interface üzerinden sunulabilir. ORM global scope kullanmak faydalıdır ancak raw SQL ve background job gibi alternatif yollar ayrıca kontrol edilmelidir. Database RLS ile birlikte kullanıldığında repository scoping defense in depth yaklaşımının application tarafındaki katmanını oluşturur.

Tenant Filtresini Zorunlu Hale Getirmek

Repository method'ları tenant context olmadan çağrılamayacak şekilde tasarlanabilir. Örneğin repository instance request başında tenant ID ile scope edilir. Developer'ın her query'ye manuel WHERE tenant_id = ? eklemesi gerekmez. Bu yaklaşım unutulan filtre riskini azaltır. Unit ve integration tests repository'nin tenant context olmadan çalışmadığını doğrulamalıdır.

Global Query Scope

Bazı ORM'ler model seviyesinde global query filter tanımlamaya imkan verir. Tenant-scoped entity her sorguda otomatik tenant predicate alır. Bu özellik developer experience'ı iyileştirir. Ancak admin sorguları veya raw SQL bu scope'u bypass edebilir. Bu nedenle global scope güçlü bir kolaylık olsa da tek güvenlik katmanı olarak görülmemelidir.

Repository Pattern

Repository pattern business logic ile data access ayrımını güçlendirir. Tenant-scoped query davranışı ortak repository base class içinde uygulanabilir. Storage modeli shared schema'dan dedicated database'e değiştiğinde business service daha az etkilenir. Testlerde repository fake veya test database ile tenant isolation doğrulanabilir. Bu abstraction hybrid model ve tenant promotion tasarımında özellikle değerlidir.

Tenant-Aware ORM

Tenant-aware ORM configuration model query'lerine otomatik tenant filtreleri ekleyebilir. Insert sırasında tenant_id server context'ten set edilebilir. Update ve delete işlemleri de tenant scope ile sınırlandırılmalıdır. Bulk operation API'lerinin global scope'u atlayıp atlamadığı ayrıca test edilmelidir. ORM behavior version upgrade'lerinde tenant isolation regression testleri çalıştırılmalıdır.

Raw SQL Kullanımında Riskler

Raw SQL ORM global filter'larını bypass edebilir. Developer sorguya tenant predicate eklemeyi unutursa shared schema'da veri sızıntısı oluşabilir. Raw SQL kullanımını belirli repository modülleriyle sınırlandırmak yararlı olabilir. PostgreSQL RLS ikinci savunma katmanı olarak bu riski azaltır. Code review ve static query wrapper yaklaşımları da tenant context'i zorunlu hale getirebilir.

Cross-Tenant Query'leri Ayrı API'lerle Sınırlandırmak

Platform analytics veya support işlemleri bazen cross-tenant sorgu gerektirir. Normal application repository'sine “ignore tenant filter” seçeneği eklemek kötüye kullanım riskini artırır. Bunun yerine admin veya reporting için ayrı data access interface ve database role kullanılabilir. Bu API read-only ve audit zorunlu hale getirilebilir. Cross-tenant sorguların nadir ve görünür olması güvenlik modelini önemli ölçüde güçlendirir.

PostgreSQL Row-Level Security (RLS) Nedir?

PostgreSQL Row-Level Security, aynı tabloda bulunan satırlara kullanıcı veya session context'e göre erişim politikası uygulamayı sağlar. Shared schema multi-tenant sistemlerde application query'sine tenant filtresi eklenmese bile database başka tenant satırlarını görünmez hale getirebilir. Policy SELECT, INSERT, UPDATE ve DELETE işlemleri için ayrı davranış tanımlayabilir. RLS güçlü bir defense in depth katmanıdır fakat database role ve table ownership ayarları yanlışsa beklenen koruma devre dışı kalabilir. Bu nedenle policy kadar runtime role tasarımı ve otomatik testler de önemlidir.

Row-Level Security Nasıl Çalışır?

RLS etkinleştirilen tabloda PostgreSQL query çalıştırırken uygun policy expression'larını satır seviyesinde uygular. Kullanıcının yalnızca belirli tenant ID'ye ait satırları görmesi sağlanabilir. INSERT ve UPDATE için yeni satırın tenant değerini doğrulayan check kuralı kullanılabilir. Policy bulunmadığında doğru role configuration altında default-deny davranışı elde edilebilir. Uygulama tenant context'i transaction veya session setting üzerinden database'e taşıyabilir.

ENABLE ROW LEVEL SECURITY

ALTER TABLE ... ENABLE ROW LEVEL SECURITY tablo üzerinde RLS mekanizmasını etkinleştirir. Ancak bu komut tek başına bütün kullanıcıların policy'ye tabi olacağını garanti etmez. Table owner ve RLS bypass yetkisine sahip roller farklı davranabilir. Bu nedenle application runtime role ayrı oluşturulmalıdır. Test ortamında gerçek runtime role ile query çalıştırmak production davranışına en yakın güvenceyi sağlar.

CREATE POLICY

CREATE POLICY hangi satırların hangi komut için erişilebilir olduğunu tanımlar. Policy tenant ID ile trusted session context'i karşılaştırabilir. SELECT, INSERT, UPDATE ve DELETE için farklı policy oluşturmak mümkündür. Policy isimleri amaçlarını açıkça ifade etmelidir. Migration pipeline policy değişikliklerini normal schema migration kadar dikkatli yönetmelidir.

USING

USING ifadesi mevcut satırların hangi koşul altında görülebileceğini veya etkilenebileceğini belirler. Tenant isolation için satırdaki tenant_id ile current tenant setting karşılaştırılabilir. SELECT ve DELETE gibi işlemlerde kritik rol oynar. Expression performansı query plan üzerinde etkili olabilir. RLS policy içinde kullanılan alanların doğru indekslenmesi önemlidir.

WITH CHECK

WITH CHECK yeni veya güncellenen satırın policy koşuluna uygun olup olmadığını kontrol eder. Bu sayede kullanıcı aktif tenant context dışında tenant_id ile kayıt ekleyemez. Yalnızca SELECT policy tanımlamak write isolation için yeterli değildir. Insert ve update senaryoları ayrıca test edilmelidir. Application katmanında tenant ID server tarafından set edilse bile database check ek güvence sağlar.

SELECT Policy

SELECT policy active tenant dışındaki satırların query sonucunda görünmesini engeller. Eksik repository filtresi olsa bile RLS başka tenant verisini gizleyebilir. Bu durum özellikle raw SQL riskini azaltır. Ancak performance açısından tenant ID index'leri ve query plan izlenmelidir. Admin veya reporting rolleri normal runtime role'den ayrı tasarlanmalıdır.

INSERT Policy

INSERT policy yeni satırın aktif tenant context ile eşleşmesini zorunlu hale getirebilir. Client başka tenant ID göndermeye çalışsa bile database operation reddedilir. Application mümkünse tenant ID'yi request body'den değil trusted context'ten set etmelidir. Policy hata mesajı client'a gereksiz iç bilgi sızdırmamalıdır. Integration tests tenant A session ile tenant B satırı eklemeyi özellikle denemelidir.

UPDATE Policy

UPDATE işlemi hem mevcut satırın hangi tenant'a ait olduğunu hem de güncelleme sonrası tenant değerinin uygunluğunu kontrol etmelidir. Yanlış policy bir satırın ownership değerinin başka tenant'a taşınmasına izin verebilir. USING ve WITH CHECK birlikte değerlendirilmelidir. Tenant ID çoğu business entity için mutable olmamalıdır. Ownership transfer gerekiyorsa özel ve audit edilen admin workflow kullanılmalıdır.

DELETE Policy

DELETE policy kullanıcının yalnızca aktif tenant'a ait satırları silebilmesini sağlar. Bulk delete işlemleri burada özellikle risklidir. Application filtre eklemese bile RLS sınır koyabilir. Cascade delete davranışları tenant integrity açısından ayrıca test edilmelidir. Silme audit log'unda tenant, actor ve resource bilgisi tutulmalıdır.

PostgreSQL RLS ile Tenant İzolasyonu

PostgreSQL RLS kullanırken en güvenli yaklaşım tenant context'i application runtime role altında transaction seviyesinde database'e taşımaktır. Policy satırdaki tenant ID ile bu trusted session bilgisini karşılaştırır. Uygulama query filter kullanmaya devam eder, RLS ise ikinci savunma katmanı sağlar. Runtime role table owner veya BYPASSRLS yetkisine sahip olmamalıdır. Default-deny davranışı ve cross-tenant testleri bu modelin production'a çıkmadan önce doğrulanmasını sağlar.

Session-Level Tenant Context

Tenant context database session değişkeni veya custom setting üzerinden taşınabilir. Policy current_setting ile aktif tenant değerini okuyabilir. Connection pooling nedeniyle session state'in yanlış request'e taşınmaması gerekir. Bu nedenle transaction-scoped setting tercih edilebilir. Context set edilmeden query çalıştığında güvenli biçimde hata veya sıfır satır davranışı tasarlanmalıdır.

current_setting Kullanımı

current_setting custom PostgreSQL configuration değerini policy içinde okumak için kullanılabilir. Uygulama transaction başında tenant ID setting'i belirler. Policy bunu satırdaki tenant ID ile karşılaştırır. Değer string olarak geldiği için doğru type dönüşümü yapılmalıdır. Missing setting davranışı otomatik testlerle doğrulanmalıdır.

Tenant Policy

Tenant policy tüm tenant-scoped tablolar için tutarlı bir kural seti uygulamalıdır. Farklı tabloların policy'lerinde farklı semantics kullanılması bakım riskini artırır. Migration helper veya schema generator ortak policy template kullanabilir. SELECT ve write policy'leri ayrı doğrulanmalıdır. Policy değişiklikleri security-sensitive code review gerektirmelidir.

Application Runtime Role

Application runtime role production request'lerini çalıştıran düşük yetkili database kullanıcısıdır. Table owner olmamalı ve RLS bypass yetkisine sahip olmamalıdır. Schema migration ayrı ve daha yüksek yetkili role ile çalıştırılabilir. Bu ayrım application bug'ının database-level güvenlik sınırını aşmasını zorlaştırır. Runtime role permissions least privilege ilkesine göre düzenli olarak gözden geçirilmelidir.

Default-Deny Yaklaşımı

Tenant context eksik veya policy tanımlanmamış durumda erişimin otomatik açılması yerine reddedilmesi daha güvenlidir. Default-deny prensibi yanlış yapılandırmanın data leak'e dönüşmesini engellemeye yardımcı olur. Yeni tenant-scoped tablo oluşturulduğunda RLS policy eklenmeden application role tarafından erişilememesi ideal bir guardrail'dir. CI migration testleri bunu kontrol edebilir. Güvenli varsayılanlar developer hatasının etkisini sınırlar.

Application Filter + RLS Defense in Depth

Application query filter performans ve açık kod davranışı sağlar. RLS ise application filtresi unutulduğunda ikinci güvenlik duvarı oluşturur. İki mekanizmayı birlikte kullanmak redundant görünse de multi-tenant güvenlikte değerli bir savunma yaklaşımıdır. Query plan her iki koşulu optimize edebilmelidir. Testler application filter kaldırılmış senaryoda bile cross-tenant data dönmediğini doğrulayabilir.

PostgreSQL RLS'nin Kritik Tuzakları

RLS güçlü olsa da yanlış role ve ownership ayarları güvenlik varsayımını bozabilir. Table owner çoğu normal durumda RLS policy'lerinden etkilenmeyebilir ve superuser veya BYPASSRLS yetkili roller policy'leri aşabilir. Application runtime kullanıcısını migration owner ile aynı yapmak bu nedenle ciddi risktir. Referential integrity ve error davranışı da bazı durumlarda tenant dışı verinin varlığı hakkında dolaylı bilgi sızdırabilir. RLS kullanılan sistemler yalnızca happy path değil, role ve bypass senaryolarıyla birlikte otomatik test edilmelidir.

Table Owner RLS Davranışı

Table owner role normal application role gibi değerlendirilmeyebilir. Uygulama connection'ı tablo sahibi olarak çalışıyorsa policy'ye güvendiğiniz halde beklenmeyen erişim oluşabilir. Bu nedenle migration owner ile runtime role ayrılmalıdır. Integration tests gerçek runtime credential kullanmalıdır. Development ortamında farklı role ile test yapmak production RLS davranışını gizleyebilir.

FORCE ROW LEVEL SECURITY

FORCE ROW LEVEL SECURITY table owner davranışını daha sıkı hale getirmek için kullanılabilir. Ancak bunun role architecture yerine geçmesi doğru değildir. Application yine ayrı düşük yetkili runtime role ile çalışmalıdır. FORCE davranışı migration ve maintenance operasyonlarıyla birlikte değerlendirilmelidir. Policy test suite owner ve runtime senaryolarını ayrı doğrulamalıdır.

Superuser

Superuser geniş database yetkisine sahip olduğu için application runtime connection için kullanılmamalıdır. RLS dahil birçok güvenlik sınırını aşabilir. Production uygulamasının superuser credential kullanması bir application bug'ını tam database compromise riskine dönüştürür. Migration ve emergency administration ayrı operational path üzerinden yürütülmelidir. Secret manager erişimleri de role seviyesine göre ayrılmalıdır.

BYPASSRLS

BYPASSRLS yetkisine sahip role RLS policy'lerini atlayabilir. Bu yetki normal application user'a verilmemelidir. Reporting veya admin ihtiyacı varsa ayrı role oluşturulmalı ve erişim audit edilmelidir. BYPASSRLS credential'ın sızması tenant isolation sınırını geniş biçimde etkiler. Yetki inventory ve secret rotation süreçleri bu riski açıkça takip etmelidir.

Application Kullanıcısını Table Owner Yapmamak

Application runtime ve schema migration rolleri ayrılmalıdır. Runtime role yalnızca gerekli SELECT, INSERT, UPDATE ve DELETE izinlerine sahip olabilir. DDL ve ownership yetkisi migration pipeline'a özel kullanıcıda kalabilir. Bu yaklaşım RLS'nin daha güvenilir çalışmasını sağlar. Least privilege aynı zamanda SQL injection veya compromised application etkisini de küçültür.

RLS Policy'lerini Otomatik Test Etmek

RLS policy testleri tenant A ve tenant B fixture'larıyla SELECT, INSERT, UPDATE ve DELETE işlemlerini çalıştırmalıdır. Runtime role ile farklı tenant verisine erişim denenmelidir. Context eksik olduğunda default-deny doğrulanmalıdır. Table owner ve elevated role testleri de yanlış credential kullanımını yakalamaya yardımcı olur. Bu testler CI pipeline'da schema migration sonrasında otomatik çalışmalıdır.

Referential Integrity Kaynaklı Bilgi Sızıntısı Riskleri

Foreign key veya unique constraint hataları başka tenant'a ait bir değerin varlığını dolaylı olarak belli edebilir. Örneğin global unique constraint tenant bazında olması gereken e-posta veya slug değerini gereksiz biçimde paylaşabilir. Constraint tasarımı tenant-aware yapılmalıdır. Error mesajları client'a ham database detaylarını göstermemelidir. Security testleri yalnızca satır okumayı değil, hata davranışından bilgi sızıntısını da değerlendirmelidir.

RLS ile Connection Pooling Nasıl Birlikte Kullanılır?

RLS tenant context'i connection state içinde taşıyorsa connection pooling tasarımı kritik hale gelir. Aynı physical connection farklı tenant request'leri tarafından yeniden kullanılabilir. Önceki request'in tenant setting'i connection üzerinde kalırsa cross-tenant veri sızıntısı riski oluşur. Transaction-scoped SET LOCAL ve açık transaction boundary bu riski azaltır. Pool reset davranışı ve PgBouncer modu gerçek production configuration ile test edilmelidir.

Connection Pool Nedir?

Connection pool uygulamanın her request için yeni database connection açmak yerine mevcut bağlantıları yeniden kullanmasını sağlar. Bu yöntem latency ve database connection maliyetini azaltır. Multi-tenant sistemde aynı connection zaman içinde farklı tenant'lar adına kullanılabilir. Bu nedenle tenant-specific session state dikkatle yönetilmelidir. Pool configuration application concurrency ve database limitlerine göre izlenmelidir.

Session Pooling

Session pooling client session boyunca aynı backend connection'ı koruyabilir. Session-level setting kullanımı teknik olarak daha kolay görünse de connection reuse ve reset davranışı yine önemlidir. Uygulama request sınırı ile database session sınırı her zaman aynı değildir. Tenant switch veya request completion sonrasında state temizlenmelidir. Transaction-scoped context daha güvenli varsayılan sağlayabilir.

Transaction Pooling

Transaction pooling modelinde backend connection yalnızca transaction süresince client'a atanabilir. Transaction bittiğinde connection başka request tarafından kullanılabilir. Session-level state bu modelde güvenilir değildir. Tenant context her transaction başlangıcında yeniden belirlenmelidir. Bu nedenle RLS policy tasarımı pool moduyla birlikte değerlendirilmelidir.

Tenant Context'in Connection'da Kalma Riski

Tenant A request'i connection üzerinde tenant setting bırakır ve connection Tenant B request'ine verilirse ciddi data leak oluşabilir. Bu hata nadir görünebilir fakat yüksek concurrency ortamında production'da ortaya çıkabilir. Context set ve reset davranışı integration testlerle doğrulanmalıdır. Connection lifecycle logları debug sırasında tenant ID'yi güvenli metadata olarak taşıyabilir. En iyi çözüm state'in transaction bitiminde otomatik kaybolacağı yöntemler kullanmaktır.

SET LOCAL Kullanımı

SET LOCAL PostgreSQL setting'ini yalnızca aktif transaction süresince geçerli hale getirir. Transaction tamamlandığında değer otomatik olarak eski durumuna döner. Bu özellik tenant RLS context'i için güçlü bir mekanizma sağlar. Her tenant-scoped query explicit transaction içinde çalışmalıdır. Transaction dışına kaçan query'ler testlerle tespit edilmelidir.

Transaction Boundary

Tenant context transaction başlamadan set edilmeli ve tüm ilgili query'ler aynı transaction içinde çalışmalıdır. Middleware veya data access wrapper bu işlemi merkezi hale getirebilir. Nested transaction ve retry davranışı ayrıca değerlendirilmelidir. Transaction gereksiz uzun tutulursa connection pool kapasitesi olumsuz etkilenebilir. Güvenlik ve performans arasında açık bir boundary tasarımı yapılmalıdır.

Connection Reset

Connection pool'a dönen bağlantının tenant-specific state taşımaması gerekir. Driver veya pool reset komutları bu konuda yardımcı olabilir. Ancak yalnızca reset'e güvenmek yerine transaction-scoped setting daha güvenli bir model oluşturur. Custom prepared state veya temporary objects da değerlendirilmelidir. Pool upgrade'lerinde reset davranışı regression testlerinden geçirilmelidir.

PgBouncer

PgBouncer PostgreSQL connection pooling için yaygın kullanılan bir araçtır ve session ile transaction pooling modları farklı davranır. Tenant context tasarımı seçilen pooling mode'a göre yapılmalıdır. Session state'e bağımlı RLS yaklaşımı transaction pooling ile uyumsuz sonuçlar üretebilir. SET LOCAL gibi transaction-scoped yöntemler daha güvenli olabilir. Production mimarisi local development connection davranışından farklıysa integration test ortamı gerçek pool topology'sini taklit etmelidir.

Pool Sonrası Tenant Context Testi

Test bir connection pool üzerinden sırayla Tenant A ve Tenant B request'leri çalıştırmalıdır. Tenant B request'inin önceki tenant state'i görmediği doğrulanmalıdır. High concurrency ile random tenant sequence testi daha değerli sonuç verir. SELECT yanında INSERT ve UPDATE işlemleri de denenmelidir. Bu test özellikle pooling library veya database proxy değiştirildiğinde CI veya staging doğrulamasının parçası olmalıdır.

Tenant-Aware Primary Key Tasarımı

Primary key tasarımı shared schema'da uniqueness ve tenant integrity üzerinde doğrudan etki yaratır. Global ID yaklaşımı her satırı sistem genelinde benzersiz yaparken tenant-local ID aynı sayıların farklı tenant'larda kullanılmasına izin verir. Composite primary key tenant ID ile entity ID'yi birlikte kullanarak sahipliği key seviyesinde görünür hale getirebilir. Hangi yaklaşımın seçileceği ORM desteği, public API ve foreign key tasarımına bağlıdır. En önemli konu key stratejisinin cross-tenant ilişki oluşturmayı kolaylaştırmaması ve migration yolunu gereksiz zorlaştırmamasıdır.

Global Primary Key

Global primary key tüm tenant'lar arasında benzersiz ID üretir. UUID veya global sequence kullanılabilir. Resource lookup ve event ID üretimi daha kolay hale gelir. Buna rağmen query tenant predicate içermeye devam etmelidir, çünkü global ID bilmek authorization sağlamaz. Foreign key'lerde tenant integrity ayrıca constraint ile korunmalıdır.

Tenant-Local Primary Key

Tenant-local key aynı entity ID değerinin farklı tenant'larda tekrar kullanılmasına imkan verir. Bu modelde gerçek uniqueness (tenant_id, entity_id) çiftiyle sağlanır. Data export veya tenant migration sırasında local ID'ler korunabilir. ORM ve API tasarımında composite key desteği kontrol edilmelidir. Resource URL'lerinde tenant context zaten bulunuyorsa model doğal biçimde çalışabilir.

Composite Primary Key

Composite primary key tenant ID ile entity ID'yi birleştirir. Bu yaklaşım child tabloların aynı tenant içindeki parent'a bağlanmasını database seviyesinde kolaylaştırır. Foreign key de aynı iki kolonu referans alabilir. İndeks boyutu global integer key'e göre daha büyük olabilir. Veri integrity avantajı performans ve ORM ergonomisiyle birlikte değerlendirilmelidir.

tenant_id

tenant_id composite key'in tenancy sınırını temsil eden parçasıdır. Query pattern çoğunlukla tenant üzerinden başladığı için index prefix açısından da faydalıdır. Foreign key ilişkilerinde child ve parent tenant eşleşmesini zorunlu hale getirebilir. Tenant transferi gerekiyorsa key değişikliği zor olabilir. Bu nedenle ownership transfer iş ihtiyacı baştan değerlendirilmelidir.

entity_id

entity_id tenant içindeki belirli kaydı temsil eder. Sequence tenant bazında üretilebilir veya global generator kullanılabilir. Composite key kullanıldığında entity ID tek başına güvenli lookup anahtarı değildir. Repository her zaman tenant context ile birlikte query yapmalıdır. API katmanında public identifier kullanılması database key stratejisinden bağımsız olabilir.

UUID ile Global Benzersizlik

UUID her entity'nin tenant'tan bağımsız global benzersiz ID'ye sahip olmasını sağlar. Event-driven sistemlerde resource referanslarını kolaylaştırabilir. Tenant migration sırasında ID collision riski azalır. Ancak UUID'nin bilinmesi başka tenant resource'una erişim hakkı vermez. Query yine tenant scope ve authorization kontrolü altında çalışmalıdır.

Hangi Yaklaşım Ne Zaman Kullanılmalı?

Basit ORM kullanımı ve global resource identification önemliyse global UUID veya sequence rahat olabilir. Database seviyesinde tenant integrity'yi foreign key ile güçlü biçimde zorlamak isteniyorsa composite key faydalı olabilir. Tenant-local ID, data portability ve tenant-level restore senaryolarında doğal davranabilir. Her model benchmark ve tooling desteği açısından test edilmelidir. Başlangıçta seçilen key stratejisi daha sonra geniş çaplı migration gerektirebileceği için erken değerlendirme önemlidir.

Tenant-Aware Unique Constraint

Shared schema'da unique constraint tasarımı tenant sınırını dikkate almalıdır. Bir e-posta, slug veya external ID yalnızca tenant içinde benzersiz olmalıysa global UNIQUE constraint yanlış davranış üretir. Composite unique constraint tenant ID ile business key'i birlikte değerlendirir. Bu yaklaşım hem doğru kullanıcı deneyimi hem database-level integrity sağlar. Hangi alanların gerçekten global unique olması gerektiği açıkça belgelenmelidir.

Kullanıcı E-Postası Örneği

Bir kullanıcı aynı e-posta adresiyle birden fazla organization'a üye olabiliyorsa e-posta global identity seviyesinde unique olabilir. Fakat tenant-specific contact tablosunda aynı e-posta farklı tenant'larda tekrar kullanılabilmelidir. Business anlamına göre constraint değişir. Data model identity ile customer contact kavramını ayırmalıdır. Unique kararını yalnızca kolon adına bakarak vermek yanlış sonuç yaratabilir.

UNIQUE(email) Problemi

Tenant-scoped tabloda UNIQUE(email) tanımı tüm tenant'lar arasında global benzersizlik zorlar. Tenant A aynı e-postayı eklediyse Tenant B gereksiz hata alabilir. Bu hata başka tenant'ta ilgili e-postanın varlığını da dolaylı biçimde sızdırabilir. Constraint tenant scope'a göre düzenlenmelidir. Error response database constraint adını client'a olduğu gibi göstermemelidir.

UNIQUE(tenant_id, email)

Composite unique constraint aynı tenant içinde duplicate e-postayı engellerken farklı tenant'ların aynı değeri kullanmasına izin verir. Shared schema için sık kullanılan doğru model budur. İndeks tenant-first query pattern'lerine de fayda sağlayabilir. Case-insensitive uniqueness gerekiyorsa normalization veya uygun index expression kullanılmalıdır. Constraint migration öncesinde mevcut duplicate data kontrol edilmelidir.

Tenant Bazlı Slug

Project veya workspace slug'ı tenant içinde benzersiz olabilir. UNIQUE(tenant_id, slug) aynı slug'ın farklı tenant'larda kullanılmasını sağlar. URL tenant path veya subdomain içeriyorsa bu semantics doğal biçimde çalışır. Slug normalization ve case sensitivity açıkça belirlenmelidir. Public URL'de slug kullanmak authorization kontrolünü ortadan kaldırmaz.

Tenant Bazlı External ID

Enterprise entegrasyonları kendi sistemlerinden external ID gönderebilir. Aynı external ID farklı tenant'larda bulunabilir. Bu nedenle constraint tenant ID ile birlikte tasarlanmalıdır. Integration lookup query'si de tenant context olmadan çalışmamalıdır. External ID'nin global unique olduğu varsayımı başka müşterilerin data import süreçlerini gereksiz biçimde sınırlar.

Global Unique Alanlar

Bazı alanlar gerçekten platform genelinde unique olabilir. Verified custom domain veya belirli public handle buna örnek olabilir. Bu durumda global constraint doğru seçimdir. Global uniqueness'ın business gerekçesi açık olmalıdır. Tenant-scoped field'ların yanlışlıkla global yapılması bilgi sızıntısı ve kullanım kısıtı oluşturabilir.

Tenant-Aware Foreign Key Tasarımı

Foreign key yalnızca referans verilen resource'un varlığını değil, aynı tenant'a ait olmasını da koruyabilmelidir. Shared schema'da child satırın Tenant A'ya, parent resource'un Tenant B'ye ait olması ciddi integrity problemidir. Application validation bu durumu kontrol edebilir fakat database constraint daha güçlü garanti sağlar. Composite foreign key tenant ID ile resource ID'yi birlikte referans alarak cross-tenant ilişkiyi engelleyebilir. Bu yaklaşım özellikle finansal veya hassas entity'lerde önemli bir defense in depth katmanıdır.

Cross-Tenant Foreign Key Riski

Child table yalnızca global parent_id referans ediyorsa application bug'ı başka tenant parent'ına ilişki kurabilir. Satır daha sonra doğru tenant filtresiyle görünse bile ilişkili veriye join sırasında sızıntı oluşabilir. Database ownership kuralını bilmiyorsa bu ilişkiyi geçerli kabul eder. Tenant-aware foreign key bu riski ortadan kaldırmaya yardımcı olur. Integration tests yanlış tenant parent ID ile insert denemelidir.

Composite Foreign Key

Composite foreign key (tenant_id, parent_id) değerini parent tablodaki aynı kolon çiftine bağlayabilir. Böylece child ile parent tenant ID eşleşmek zorunda kalır. Bu model composite unique veya primary key gerektirir. ORM mapping biraz daha fazla yapılandırma isteyebilir. Güvenlik ve veri integrity avantajı özellikle shared schema'da değerlidir.

Tenant ID'nin Parent ve Child Tablolarda Bulunması

Child tabloda tenant ID tekrar tutulması normalizasyon açısından gereksiz görünebilir. Fakat tenant-first query, RLS ve composite foreign key için önemli fayda sağlar. Parent join olmadan satırın tenant sahipliği doğrudan anlaşılır. Data export ve partitioning işlemleri de kolaylaşabilir. Bu nedenle kontrollü denormalization multi-tenant integrity açısından mantıklı bir tercih olabilir.

Database Seviyesinde Tenant Integrity

Database constraint application hangi kod yolunu kullanırsa kullansın ownership kuralını korur. Raw SQL, migration script veya background worker hata yapsa bile invalid cross-tenant ilişki reddedilir. Bu yaklaşım güvenlik sorumluluğunu yalnızca application developer'a bırakmaz. Constraint isimleri ve migration strategy açık tutulmalıdır. Performance etkisi benchmark edilerek uygun index'ler oluşturulmalıdır.

Uygulama Kontrolüne Güvenmemenin Avantajı

Application validation gereklidir fakat farklı code path'lerde unutulabilir. Database constraint merkezi ve her yazma operasyonuna uygulanan bir güvenlik sınırı sağlar. Böylece bir endpoint bug'ı doğrudan data corruption'a dönüşmeyebilir. Application yine kullanıcıya anlaşılır error vermelidir. Defense in depth yaklaşımı shared schema multi-tenant sistemlerde özellikle değerlidir.

Shared Schema İçin İndeksleme Stratejisi

Shared schema'da birçok sorgu önce tenant scope ile filtrelendiği için indeks tasarımı bu pattern'e uygun olmalıdır. (tenant_id, created_at) veya (tenant_id, status) gibi composite index'ler sık kullanılan tenant-scoped sorguları hızlandırabilir. Ancak tenant ID'yi her index'te ilk kolon yapmak otomatik olarak doğru değildir. Query selectivity, sort order ve global admin sorguları birlikte değerlendirilmelidir. Gerçek production query plan'ları tenant boyutuna göre izlenmeli ve en büyük tenant senaryoları ayrıca benchmark edilmelidir.

Tenant-First Composite Index

Tenant-first index aynı tenant'ın satırlarını index içinde yakın gruplandırabilir. Çoğu request tek tenant scope ile çalışıyorsa query planner için verimli olabilir. İkinci kolon filter veya sort ihtiyacına göre seçilir. Tenant başına veri dağılımı çok dengesizse selectivity ayrıca incelenmelidir. Index sayısını gereksiz büyütmek write cost ve storage kullanımını artırır.

(tenant_id, created_at)

Zamana göre sıralanan tenant feed veya activity query'lerinde bu index oldukça kullanışlıdır. Query WHERE tenant_id = ? ORDER BY created_at DESC pattern'ine iyi uyum sağlayabilir. Pagination cursor da created_at ile tasarlanabilir. Büyük tenant'larda index scan davranışı production plan'larıyla izlenmelidir. Created_at tek başına global analytics için farklı index ihtiyacı doğurabilir.

(tenant_id, status)

Tenant içindeki kayıtları durum değerine göre filtreleyen sorgular için bu composite index faydalıdır. Örneğin açık task veya aktif invoice sorguları hızlanabilir. Status cardinality düşük olsa bile tenant filter ile birlikte anlamlı selectivity sağlanabilir. Ek kolonlar covering index amacıyla değerlendirilirken write overhead dikkate alınmalıdır. Index yalnızca gerçekten kullanılan query pattern için oluşturulmalıdır.

(tenant_id, foreign_key)

Child entity'lerin parent resource altında listelenmesi sık görülen sorgu tipidir. Tenant ID ile foreign key'i birleştiren index hem isolation predicate hem ilişki filtresini destekler. Composite foreign key constraint de benzer index ihtiyacı oluşturabilir. Join performansı büyük tenant dataset'inde test edilmelidir. Global parent lookup ihtiyacı varsa ayrı index tasarımı gerekebilir.

Unique Composite Index

Tenant-scoped uniqueness için composite unique index kullanılır. (tenant_id, slug) veya (tenant_id, external_id) buna örnektir. Bu index hem integrity hem lookup performansı sağlar. Normalization ve collation behavior ürün beklentisiyle uyumlu olmalıdır. Duplicate migration temizliği constraint eklemeden önce yapılmalıdır.

Index Selectivity

Selectivity index'in sorgu için ne kadar ayırt edici olduğunu gösterir. Tenant ID tek başına milyonlarca satırlık büyük tenant'ta çok seçici olmayabilir. İkinci kolon query pattern'ine göre önemli hale gelir. Query planner statistics tenant dağılımını yeterince temsil etmelidir. Büyük tenant ve küçük tenant plan'larının farklı davranması gözlemlenebilir.

Tenant ID Her Index'te İlk Kolon Olmalı mı?

Hayır, index sırası gerçek query pattern'ine göre belirlenmelidir. Tenant-scoped uygulama query'lerinde çoğu zaman ilk kolon mantıklıdır. Fakat global background job veya zaman bazlı maintenance query'si farklı index düzeni gerektirebilir. Gereksiz duplicate index'ler write performance ve storage maliyetini büyütür. Production slow query log ve execution plan verileri tasarım kararını yönlendirmelidir.

Shared Schema'da Query Tasarımı

Shared schema query'leri tenant predicate'i güvenli ve tutarlı biçimde taşımalıdır. Filtering, pagination, sorting, aggregate ve join işlemleri tenant scope'u korumalıdır. Query timeout ve workload kontrolü büyük tenant'ın sistemi zorlamasını engellemeye yardımcı olur. Cross-tenant query ihtiyacı normal application yolundan ayrılmalıdır. Query plan'ları tenant büyüklüğüne göre farklı davranabileceği için observability tenant ID boyutuyla zenginleştirilmelidir.

Tenant Predicate

Her tenant-scoped query aktif tenant ID ile sınırlandırılmalıdır. Repository global scope bu predicate'i otomatik ekleyebilir. PostgreSQL RLS ikinci güvenlik katmanı sunar. Query builder tenant context olmadan çalışmamalıdır. Missing predicate testleri code review kadar otomatik integration testlerle de yakalanmalıdır.

Query Plan

Query planner tenant dağılımına göre farklı execution strategy seçebilir. Küçük tenant için index scan iyi çalışırken çok büyük tenant için farklı plan gerekebilir. Statistics güncelliği önemlidir. Parameterized query ve generic plan davranışı tenant skew olduğunda incelenmelidir. Slow query monitoring tenant ve query fingerprint'i birlikte göstermelidir.

Pagination

Offset pagination büyük tenant'larda derin sayfalarda pahalı hale gelebilir. Cursor pagination tenant ID ve stable sort key ile daha verimli olabilir. Cursor başka tenant'a taşınamamalı veya context ile doğrulanmalıdır. Sorting deterministic olmalıdır. Pagination query'si tenant-first index ile uyumlu tasarlanmalıdır.

Sorting

Tenant içindeki liste sorguları sık kullanılan sort alanlarına göre indexlenebilir. Sort parametresi allowlist üzerinden kontrol edilmelidir. Dynamic SQL injection riski önlenmelidir. Büyük dataset'te memory sort maliyeti noisy neighbor etkisi yaratabilir. Query timeout ve pagination bu yükü sınırlamaya yardımcı olur.

Aggregate Query

Tenant dashboard için count, sum veya group by sorguları büyük veri hacminde pahalı olabilir. Pre-aggregation, cache veya read replica kullanılabilir. Aggregate her zaman tenant scope içinde çalışmalıdır. Cross-tenant platform analytics ayrı pipeline'a taşınabilir. OLTP database'i ağır analytics için sürekli kullanmak diğer tenant'ların latency değerini bozabilir.

Join

Join edilen tüm tenant-scoped tablolar aynı tenant'a ait olmalıdır. Composite foreign key data integrity sağlar. Query condition yalnızca resource ID'ye güvenmemelidir. RLS her tabloda ayrı policy uygulayabilir. Join plan'ı büyük tenant verisinde benchmark edilmelidir.

Cross-Tenant Query

Cross-tenant query normal user request path içinde bulunmamalıdır. Platform analytics veya admin ihtiyaçları için ayrı role ve API tasarlanabilir. Query read-only olabilir ve audit zorunlu tutulabilir. Hassas alanlar maskelenebilir. Bu ayrım accidental cross-tenant data access riskini azaltır.

Query Timeout

Query timeout tek bir tenant'ın sınırsız database kaynağı tüketmesini engeller. Interactive request ile background analytics için farklı timeout politikaları olabilir. Timeout sonrası client'a retry veya async report seçeneği sunulabilir. Tenant bazlı heavy query metric'i tutulmalıdır. Büyük tenant için dedicated database promotion kararı bu veriden destek alabilir.

Noisy Neighbor Problemi Nedir?

Noisy neighbor, bir tenant'ın aşırı kaynak tüketiminin aynı altyapıyı paylaşan diğer tenant'ların performansını bozmasıdır. Shared database modelinde CPU, memory, disk I/O, lock ve connection pool ortak kaynaklardır. Tek bir büyük rapor veya background job diğer müşterilerin latency SLO'larını etkileyebilir. Bu sorun yalnızca büyük tenant'tan kaynaklanmaz, yanlış query veya runaway job küçük tenant'ta da oluşabilir. Tenant bazlı resource telemetry ve workload kontrolü noisy neighbor riskini yönetmenin temelidir.

Büyük Tenant

Büyük tenant diğerlerinden yüz kat daha fazla satır ve trafik üretebilir. Ortalama tenant metrikleri bu farkı gizleyebilir. Query ve index stratejisi en büyük tenant dataset'i ile test edilmelidir. Storage ve backup süresi de tenant büyüklüğüyle birlikte izlenmelidir. Belirli eşik aşıldığında tenant dedicated database'e veya ayrı shard'a taşınabilir.

Yoğun Query

Complex report veya yanlış join kısa sürede yüksek CPU ve I/O tüketebilir. Query timeout ve statement monitoring bu davranışı sınırlayabilir. Tenant ID slow query metadata'sına eklenmelidir. Sık kullanılan ağır raporlar async job ve materialized aggregation üzerinden çalıştırılabilir. Query cost ürün quota'sına dönüştürülebilir.

CPU

CPU saturation tüm tenant request'lerinin latency değerini yükseltebilir. Query fingerprint ve tenant attribution hangi workload'un kaynak tükettiğini gösterir. Read replica bazı read-heavy yükleri ayırabilir. Background job concurrency sınırlandırılabilir. Sürekli yüksek CPU üreten tenant farklı isolation tier'e taşınabilir.

Memory

Büyük sort, hash join veya connection sayısı database memory tüketimini artırabilir. Bir tenant'ın yoğun workload'u diğer sorguların disk'e spill olmasına neden olabilir. Query memory limitleri ve concurrency control yardımcı olur. Tenant-level heavy query monitoring kurulmalıdır. Cache ve precomputation bazı rapor ihtiyaçlarını hafifletebilir.

Disk I/O

Full table scan, backup veya büyük batch update disk I/O kapasitesini tüketebilir. Shared storage kullanan diğer tenant'lar doğrudan etkilenir. Query plan ve maintenance job scheduling önemlidir. Read replica veya dedicated storage ile workload ayrılabilir. I/O metric'leri tenant ve query fingerprint ile ilişkilendirildiğinde problem kaynağı daha hızlı bulunur.

Lock Contention

Uzun transaction veya yüksek write concurrency lock wait sürelerini artırabilir. Tenant-scoped satırlarda bile aynı index veya table-level operation diğer tenant'ları etkileyebilir. Migration ve large update işlemleri düşük trafik döneminde planlanmalıdır. Lock monitoring tenant attribution ile zenginleştirilebilir. Application transaction'ları gereksiz uzun tutulmamalıdır.

Connection Kullanımı

Tek tenant aşırı parallel request üreterek connection pool'u tüketebilir. Diğer tenant'lar connection beklemek zorunda kalır. Tenant rate limit ve application concurrency limit bu riski azaltır. Pool metrics tenant request queue ile birlikte izlenmelidir. Dedicated tenant için ayrı pool veya database route gerekebilir.

Diğer Tenant'ların SLO'larına Etkisi

Noisy neighbor problemi ancak diğer tenant latency ve availability değerleri ölçülüyorsa net biçimde görülebilir. Global p95 normal görünürken küçük tenant grubu ciddi yavaşlama yaşayabilir. Tenant SLO dashboard bu nedenle önemlidir. Heavy tenant workload başladığında komşu tenant metrikleri karşılaştırılmalıdır. Isolation tier kararları yalnızca maliyet değil SLO etkisine göre de verilebilir.

Noisy Neighbor Nasıl Kontrol Edilir?

Noisy neighbor kontrolü tek bir database ayarıyla çözülmez. Tenant bazlı rate limit, query timeout, workload queue, background job concurrency ve resource quota birlikte kullanılabilir. Read-heavy yük read replica'ya taşınabilir, caching aynı sorguların tekrar çalışmasını azaltabilir. En büyük tenant'ın sürekli ayrı kaynak gerektirdiği noktada dedicated database promotion ekonomik hale gelebilir. Kontrol mekanizmaları gerçek tenant SLO ve cost attribution verisiyle ayarlanmalıdır.

Tenant Bazlı Rate Limiting

Rate limit request sayısını tenant bazında sınırlar. Tek tenant'ın API gateway veya application worker kapasitesini tüketmesini engeller. Free ve enterprise tier için farklı quota uygulanabilir. Burst ve sustained limit ayrı tasarlanabilir. Limit aşıldığında açık 429 response ve retry bilgisi verilmelidir.

Query Timeout

Database statement timeout uzun çalışan sorguların sınırsız kaynak tüketmesini engeller. Interactive request için daha kısa, background report için daha uzun süre belirlenebilir. Timeout sonrası job async moda alınabilir. Tenant bazlı timeout farklılaştırması dikkatle yapılmalıdır. Sürekli timeout olan sorgular ürün ve index tasarımı açısından incelenmelidir.

Workload Queue

Ağır işlerin request thread içinde doğrudan database'e gitmesi yerine queue üzerinden çalıştırılması concurrency kontrolü sağlar. Tenant başına job limit belirlenebilir. Worker scheduler adil paylaşım uygulayabilir. Büyük tenant'ın binlerce rapor job'u diğer müşterileri bloklamamalıdır. Queue depth ve tenant wait time monitoring yapılmalıdır.

Background Jobs

Background job'lar tenant context ile çalışmalı ve resource limitlerine tabi olmalıdır. Aynı tenant için parallel job sayısı sınırlandırılabilir. Retry storm noisy neighbor etkisini büyütebilir. Dead letter queue sürekli başarısız işleri izole eder. Worker telemetry job türü ve tenant ID ile etiketlenmelidir.

Read Replica

Read-heavy dashboard ve rapor sorguları replica'ya yönlendirilebilir. Bu yöntem primary write workload'unu rahatlatır. Replica lag kabul edilebilir ürün davranışıyla uyumlu olmalıdır. Tenant-specific critical read'ler stale data tolere etmiyorsa primary kullanılabilir. Büyük analytics workload ayrı warehouse'a taşınmalıdır.

Resource Quotas

Storage, request, job veya query quota tenant tüketimini kontrollü hale getirir. Quota subscription tier ile ilişkilendirilebilir. Hard limit ve soft alert farklı kullanılabilir. Enterprise tenant için daha yüksek kaynak ayrılabilir. Resource quota kullanıcıya şeffaf biçimde gösterildiğinde operasyonel sürprizler azalır.

Caching

Sık okunan tenant verisini cache'lemek database yükünü azaltabilir. Cache key her zaman tenant ID içermelidir. Hot tenant cache kapasitesini tamamen tüketmemelidir. Tenant bazlı TTL veya eviction stratejisi değerlendirilebilir. Cache invalidation cross-tenant isolation testlerinin parçası olmalıdır.

Büyük Tenant'ı Ayrı Database'e Taşımak

Sürekli yüksek CPU, I/O veya storage tüketen tenant shared pool için ekonomik olmaktan çıkabilir. Hybrid architecture bu tenant'ı dedicated database'e taşımayı mümkün kılar. Data copy, CDC ve controlled cutover gerekir. Tenant directory routing güncellenir. Taşıma sonrası shared pool kaynak kullanımındaki iyileşme ölçülmelidir.

Model 2: Schema-Per-Tenant

Schema-per-tenant modelinde her tenant aynı database sunucusunu paylaşırken ayrı database schema kullanır. Bu yaklaşım shared schema'ya göre namespace düzeyinde daha açık ayrım sağlar. Tenant-specific backup veya customization bazı durumlarda daha kolay olabilir. Fakat tenant sayısı büyüdükçe migration fan-out ve schema lifecycle yönetimi önemli iş yükü oluşturur. Otomatik provisioning ve migration orchestrator olmadan schema-per-tenant sistemler kısa sürede operasyon ekibine ağır yük getirebilir.

Schema-Per-Tenant Nasıl Çalışır?

Her tenant için örneğin tenant_123 gibi ayrı schema bulunur. Aynı tablo yapıları her schema içinde tekrar oluşturulur. Request tenant context üzerinden doğru schema'ya yönlendirilir. Connection üzerinde search_path değiştirilebilir veya schema-qualified query kullanılabilir. Shared global tablolar public schema veya ayrı control schema içinde tutulabilir.

Tenant Schema Oluşturmak

Tenant provisioning sırasında yeni schema güvenli ve standardize isimle oluşturulur. Schema adı client input'tan doğrudan SQL'e eklenmemelidir. Mapping tenant directory tarafından yönetilebilir. Schema creation migration tool üzerinden idempotent çalışmalıdır. Provisioning failure durumunda cleanup ve retry mekanizması bulunmalıdır.

search_path

search_path unqualified table isimlerinin hangi schema'da aranacağını belirler. Tenant request başında doğru schema seçmek query kodunu sadeleştirebilir. Connection pooling kullanıldığında eski tenant search path'inin sonraki request'e kalmaması gerekir. Transaction-local configuration veya explicit reset kullanılmalıdır. Security açısından schema injection ve unsafe identifier kullanımı engellenmelidir.

Tenant Routing

Tenant resolver aktif tenant ID'yi schema mapping ile eşleştirir. Repository veya connection wrapper doğru schema context'i oluşturur. Business logic schema adını bilmek zorunda kalmamalıdır. Tenant directory migration sırasında schema location değişikliklerini takip edebilir. Routing failure güvenli biçimde request'i reddetmelidir.

Schema Bazlı Permission

Database role'ler belirli schema'lara erişim verecek şekilde tasarlanabilir. Tenant başına role oluşturmak izolasyonu artırabilir fakat role sayısı büyüdükçe operasyon yükü artar. Application'ın ortak runtime role kullanması durumunda schema selection application katmanında daha kritik hale gelir. Permission modeli migration ve provisioning automation ile birlikte yönetilmelidir. Admin role normal request path'inden ayrılmalıdır.

Avantajları

Tenant tabloları namespace düzeyinde ayrıldığı için yanlış query'nin başka tenant tablosuna erişmesi shared schema'ya göre daha zor olabilir. Tenant-specific schema export ve restore işlemleri daha doğrudan yapılabilir. Belirli tenant'lara küçük schema extension uygulamak teknik olarak mümkün olabilir. Aynı database infrastructure paylaşılmaya devam eder. Bu model orta sayıda tenant ve belirli izolasyon ihtiyacında dengeli bir seçenek olabilir.

Dezavantajları

Her migration yüzlerce veya binlerce schema üzerinde çalıştırılmak zorundadır. Bir tenant migration'da başarısız olduğunda schema version drift oluşabilir. Database catalog büyüklüğü ve planning overhead tenant sayısı arttıkça sorun yaratabilir. Connection state ve search path leakage ek güvenlik riski oluşturur. Bu nedenle tenant sayısı çok yüksek olacaksa schema-per-tenant modeli dikkatli değerlendirilmelidir.

Hangi Projelerde Kullanılmalı?

Orta sayıda B2B tenant, belirli tenant-level restore veya schema ayrımı ihtiyacı varsa uygun olabilir. Çok küçük binlerce tenant için operasyon maliyeti shared schema'dan daha yüksek olacaktır. Az sayıda büyük enterprise tenant için database-per-tenant daha açık izolasyon sağlayabilir. Schema customization gerekiyorsa migration maliyeti özellikle hesaplanmalıdır. Model seçimi tenant sayısının beş yıl sonraki tahminiyle birlikte yapılmalıdır.

Schema-Per-Tenant Provisioning

Schema-per-tenant modelinin başarısı yeni tenant oluşturma sürecinin tamamen otomatik olmasına bağlıdır. Tenant kaydı oluşturulduktan sonra schema, tablolar, migration version ve gerekli seed data hazırlanmalıdır. Database role veya permission değişiklikleri de aynı workflow içinde yapılabilir. Provisioning state control plane içinde takip edilmelidir. Adımlardan biri başarısız olduğunda retry ve cleanup davranışı idempotent tasarlanmalıdır.

Tenant Oluşturma

Provisioning önce control plane içinde tenant metadata kaydı oluşturur. Tenant başlangıçta provisioning state'inde tutulabilir. User-facing access tamamlanmadan verilmemelidir. Workflow ID audit ve retry için saklanabilir. Tenant ID schema mapping'in temel girdisini oluşturur.

Schema Oluşturma

Database içinde tenant'a ait schema otomasyon tarafından oluşturulur. Identifier güvenli biçimde generate edilmelidir. Aynı workflow tekrar çalıştığında duplicate schema hatası vermemesi için idempotent logic kullanılabilir. Ownership doğru migration role'a atanmalıdır. Runtime role gerekli minimum permission'ı almalıdır.

Tables Oluşturma

Yeni schema içindeki tablolar canonical migration set üzerinden oluşturulmalıdır. Her tenant için elle DDL üretmek drift riskini artırır. Current schema version yeni tenant'a doğrudan uygulanabilir. Index ve constraint'ler aynı migration artefact'ından oluşturulmalıdır. Provisioning tamamlanmadan health verification yapılmalıdır.

Initial Migration

Initial migration schema'yı current application version ile uyumlu hale getirir. Eski migration'ları tek tek çalıştırmak yerine snapshot veya baseline kullanılabilir. Migration sonucu schema version table'a yazılır. Failure tenant activation'ını durdurmalıdır. Error state dashboard üzerinden görülebilmelidir.

Seed Data

Tenant'a özel varsayılan role, configuration veya template kayıtları seed edilebilir. Seed işlemleri tekrar çalışmaya dayanıklı olmalıdır. Global lookup data gereksiz yere her schema'ya kopyalanmamalıdır. Tenant-specific seed version değişikliği migration olarak yönetilebilir. Provisioning sonrası data validation yapılmalıdır.

Database Roles

Schema permission modeline göre tenant-specific veya shared runtime role kullanılabilir. Tenant başına role güçlü ayrım sağlar fakat role sayısını büyütür. Shared role kullanılıyorsa search path ve tenant routing kontrolleri daha önemli hale gelir. Role provisioning secret management ile birlikte düşünülmelidir. Least privilege prensibi korunmalıdır.

Provisioning Durumu

Control plane tenant'ın hangi provisioning aşamasında olduğunu takip etmelidir. pending, schema_created, migrated ve active gibi state'ler kullanılabilir. UI veya support ekibi hatanın nerede olduğunu görebilir. State transition idempotent olmalıdır. Tenant active olmadan application request almamalıdır.

Provisioning Retry

Database veya network failure provisioning'i yarıda bırakabilir. Retry aynı adımları güvenli biçimde tekrar çalıştırmalıdır. Her step completion kaydı tutulabilir. Partial resource cleanup gerektiğinde otomatik compensation uygulanabilir. Manual support müdahalesi son seçenek olmalıdır.

Schema-Per-Tenant Migration Problemi

Schema-per-tenant modelinin en büyük operasyon maliyetlerinden biri her schema'yı yeni version'a taşımaktır. Tek migration değişikliği yüzlerce tenant schema'sına fan-out edilir. Tüm tenant'ları aynı anda migrate etmek database üzerinde ağır DDL yükü oluşturabilir. Canary tenant, migration queue, concurrency limit ve failure isolation bu riski yönetmeye yardımcı olur. Her schema'nın current version bilgisi merkezi dashboard'da görünür olmalıdır.

Migration Fan-Out

Bir application release tek schema yerine tenant sayısı kadar migration execution gerektirir. Tenant sayısı arttıkça toplam süre uzar. Her migration aynı anda çalıştırılırsa lock ve I/O problemi oluşabilir. Queue ve concurrency limit workload'u kontrol eder. Migration idempotent ve retryable tasarlanmalıdır.

Yüzlerce Schema'ya Migration

Yüzlerce schema üzerinde DDL çalıştırmak deployment süresini ciddi biçimde uzatabilir. Database catalog ve lock davranışı izlenmelidir. Tenant batch'leri halinde rollout daha güvenlidir. İlk küçük cohort başarıyla tamamlandıktan sonra genişletilebilir. Failure rate belirli eşiği aşarsa rollout otomatik durdurulabilir.

Schema Version Tablosu

Her tenant schema current migration version bilgisini saklamalıdır. Control plane bu bilgiyi cache veya inventory içinde toplayabilir. Application belirli minimum version altında olan tenant'ı migration state'e alabilir. Drift dashboard sorunlu tenant'ları görünür hale getirir. Restore sonrası schema version doğrulaması özellikle önemlidir.

Migration Queue

Migration queue tenant schema'larını kontrollü sırayla işler. Priority enterprise veya internal tenant'a göre belirlenebilir. Worker concurrency database kapasitesine göre ayarlanır. Retry ve dead state ayrı tutulur. Queue progress deployment dashboard'a aktarılabilir.

Parallel Migration

Migration tamamen serial çalışırsa çok uzun sürebilir. Belirli sayıda tenant paralel migrate edilerek süre kısaltılabilir. Concurrency database CPU, lock ve I/O kapasitesini aşmamalıdır. Dynamic throttling kullanılabilir. Failure bir tenant'ı etkilerken diğer worker'lar güvenli biçimde devam edebilir.

Retry

Temporary lock veya network probleminde migration yeniden denenebilir. DDL adımları idempotent veya migration state-aware olmalıdır. Blind retry data corruption riskini artırabilir. Error sınıfına göre retry policy uygulanmalıdır. Belirli sayıda başarısızlık sonrası manual review state'e geçilebilir.

Failure Isolation

Tek tenant schema'sında hata oluşması tüm rollout'u otomatik olarak bozmak zorunda değildir. Ancak aynı hata belirli oranda tekrarlanıyorsa global problem olabilir. Tenant-specific failure ve systemic failure ayrılmalıdır. Migration orchestrator threshold üzerinden rollout'u durdurabilir. Problemli tenant ayrı queue'ya alınabilir.

Rollback

DDL rollback her migration türünde kolay değildir. Expand-and-contract approach geri dönüş ihtiyacını azaltır. Destructive adımlar application compatibility doğrulandıktan sonra daha sonra uygulanabilir. Tenant-specific rollback gerekiyorsa schema version ve backup stratejisi hazır olmalıdır. Rollback planı release öncesinde yazılmalıdır.

Canary Tenant Migration

Canary migration schema değişikliğini önce küçük ve kontrollü tenant grubunda çalıştırarak production riskini azaltır. Internal tenant veya düşük riskli küçük müşteriler ilk cohort olabilir. Migration sonrası schema integrity, query latency ve application error rate izlenir. Sonuçlar sağlıklıysa rollout daha geniş tenant grubuna açılır. Sorun görülürse yüzlerce schema etkilenmeden süreç durdurulur.

Internal Tenant

Şirket içi veya test amaçlı production benzeri tenant ilk canary için uygundur. Gerçek uygulama davranışını temsil etmelidir. Migration sonrası temel business flow'lar çalıştırılır. Internal tenant'ın çok küçük ve yapay olması gerçek edge case'leri kaçırabilir. Mümkün olduğunca representative data kullanılmalıdır.

Küçük Tenant Grubu

İlk internal doğrulamadan sonra birkaç gerçek tenant seçilebilir. Tenant boyutu ve kullanım şekli çeşitlilik göstermelidir. Error ve performance metric'leri ayrı izlenir. Support ekibi gerekli durumda bilgilendirilebilir. Sonraki rollout kararına ölçülebilir veri sağlar.

Migration Validation

Migration sonrası table, index, constraint ve schema version doğrulanmalıdır. Application smoke testleri gerçek query'ler çalıştırmalıdır. Data row count ve critical invariant kontrol edilebilir. Latency regression ayrıca izlenmelidir. Validation başarısızsa rollout otomatik durdurulmalıdır.

Genişletilmiş Rollout

Canary sağlıklıysa tenant batch boyutu kademeli artırılabilir. Her wave sonrasında observation süresi bırakılır. Database load yükseliyorsa concurrency azaltılabilir. Enterprise tenant'lar ayrı daha kontrollü cohort'ta tutulabilir. Rollout dashboard tamamlanma oranını göstermelidir.

Başarısız Migration'ı Durdurmak

Error threshold veya data validation failure otomatik stop condition olabilir. Yeni tenant migration'ları queue'da bekletilir. Problemli schema durumu kaydedilir. Root cause çözülmeden rollout devam ettirilmemelidir. Bu mekanizma widespread schema drift riskini azaltır.

Tenant Bazında Rollback

Bazı migration'lar belirli tenant'a özel rollback gerektirebilir. Backward-compatible expand-and-contract tasarım bunu daha güvenli hale getirir. Destructive DDL uygulanmışsa restore gerekebilir. Rollback sonrası application version compatibility doğrulanmalıdır. Tenant directory migration state'i doğru biçimde güncellenmelidir.

Schema-Per-Tenant Connection Pooling

Schema-per-tenant modelinde connection pool genellikle tenant'lar arasında paylaşılır. Her request doğru schema context'i set etmek zorundadır. search_path connection state olduğu için pool reuse sırasında tenant context leakage riski vardır. Transaction-local schema selection ve connection reset güvenli yaklaşım oluşturur. Tenant başına ayrı pool açmak schema sayısı arttıkça connection explosion sorununa yol açabilir.

Shared Connection Pool

Tek pool birçok tenant request'ini database'e taşır. Bu model connection sayısını kontrol altında tutar. Her request connection aldıktan sonra doğru schema context'i kurmalıdır. Pool'a dönmeden önce state temizlenmelidir. Testler aynı connection üzerinde arka arkaya farklı tenant request'leri çalıştırmalıdır.

search_path Değiştirme

Tenant schema seçimi için search_path değiştirilebilir. Identifier güvenli allowlist veya directory mapping'den gelmelidir. Client input doğrudan SQL identifier'a çevrilmemelidir. Transaction-local ayar tercih edilebilir. Query sonunda path'in başka tenant request'ine sızmadığı doğrulanmalıdır.

Connection State

Connection üzerinde search path, temp table veya custom setting gibi state kalabilir. Pool reuse bu state'i farklı request'e taşıyabilir. Tenant isolation açısından state management kritik önemdedir. Driver ve proxy reset davranışı belgelenmelidir. Integration test gerçek production pooling configuration'ını taklit etmelidir.

Tenant Context Leakage

Tenant A için ayarlanmış schema context Tenant B request'ine geçerse yanlış tablolara erişim gerçekleşebilir. Bu tür hata düşük concurrency testinde görünmeyebilir. Randomized high concurrency test değerli olur. Transaction-scoped configuration riski azaltır. Her tenant response doğruluğu resource fixture'larıyla kontrol edilmelidir.

Transaction Bazlı Schema Seçimi

Schema seçimini transaction başlangıcında yapmak context'in transaction bitiminde temizlenmesini kolaylaştırır. Tüm tenant query'leri aynı transaction içinde çalıştırılmalıdır. Long transaction pool kapasitesini azaltabilir. Read-only request'ler için de kısa transaction kullanılabilir. Repository wrapper bu davranışı merkezi hale getirebilir.

Connection Reset

Pool'a dönen connection'ın default schema ve state'e dönmesi gerekir. Explicit reset command veya driver hook kullanılabilir. Reset failure security event olarak ele alınmalıdır. Transaction-local state tercih edilirse ek koruma sağlanır. Library upgrade sonrası reset regression testi çalıştırılmalıdır.

Pool Exhaustion

Her tenant için ayrı connection veya uzun transaction kullanmak pool'u hızla tüketebilir. Shared pool ve tenant rate limiting bu riski azaltır. Connection wait time tenant SLO'larını etkileyebilir. Pool size database connection limitleriyle uyumlu ayarlanmalıdır. Heavy tenant workload farklı queue veya dedicated database'e yönlendirilebilir.

Model 3: Database-Per-Tenant

Database-per-tenant modelinde her tenant fiziksel veya mantıksal olarak ayrı database kullanır. Bu yapı güçlü veri izolasyonu, tenant-level backup ve restore açısından önemli avantajlar sunar. Enterprise müşteri, data residency ve compliance gereksinimlerinde özellikle değerlidir. Buna karşılık tenant sayısı arttıkça connection routing, credential, migration ve monitoring otomasyonu zorunlu hale gelir. Tenant directory bu modelin merkezinde bulunur ve her tenant'ın database location, endpoint, region ve schema version bilgisini güvenilir biçimde tutar.

Database-Per-Tenant Nasıl Çalışır?

Her tenant'ın application data'sı ayrı database içinde tutulur. Request tenant context çözüldükten sonra tenant directory doğru database endpoint'ini döndürür. Data access layer dynamic connection routing yapar. Database credential tenant-specific veya shared low-privilege modelde tasarlanabilir. Application business logic aynı repository interface üzerinden farklı tenant database'lerine erişebilir.

Tenant Directory

Tenant directory tenant ID ile storage location arasındaki mapping'i tutar. Database endpoint, region, schema version ve isolation tier temel alanlardır. Bu kayıt control plane'in kritik parçasıdır. Directory unavailable olduğunda data plane'in tamamen durmaması için caching veya replicated read model kullanılabilir. Routing update atomik ve audit edilebilir olmalıdır.

Dynamic Connection Routing

Repository request başında tenant ID'ye göre doğru database connection'ı seçer. Pool lazy biçimde oluşturulabilir. Connection string application code içinde sabit bulunmamalıdır. Routing logic centralized service veya connection resolver üzerinden yönetilmelidir. Yanlış tenant-to-database mapping ciddi güvenlik problemi olduğundan integration testlerle doğrulanmalıdır.

Tenant Database Credential

Her tenant için ayrı database credential kullanmak credential leak etki alanını küçültebilir. Ancak secret sayısı büyüdükçe yönetim maliyeti artar. Secret manager ve automated rotation gereklidir. Application kısa süreli cache kullanabilir. Credential least privilege prensibine göre yalnızca ilgili database'e erişebilmelidir.

Dedicated Database

Dedicated database tenant workload'unu diğerlerinden daha belirgin biçimde ayırır. Backup, restore ve maintenance tenant bazında planlanabilir. Enterprise customer için performans ve compliance avantajı sağlar. Ancak altyapı tamamen dedicated instance olmak zorunda değildir, aynı cluster içindeki ayrı database de kullanılabilir. İzolasyon seviyesi ürün sözleşmesinde açık biçimde tanımlanmalıdır.

Avantajları

Cross-tenant query riski schema seviyesinde büyük ölçüde azalır. Tenant bazlı restore ve data export daha kolaydır. Region ve encryption policy tenant bazında uygulanabilir. Büyük tenant'ın noisy neighbor etkisi farklı resource boundary ile sınırlandırılabilir. Enterprise isolation tier olarak ürünleştirilebilir.

Dezavantajları

Database sayısı arttıkça provisioning, migration ve connection yönetimi büyür. Her tenant için ayrı pool açmak connection explosion yaratabilir. Schema version drift ihtimali vardır. Cross-tenant analytics ayrı data warehouse gerektirebilir. Bu nedenle database-per-tenant otomasyon olmadan ölçeklenmesi zor bir modeldir.

Hangi SaaS İçin Uygundur?

Az veya orta sayıda büyük enterprise tenant için güçlü seçenektir. Finans, sağlık veya data residency gerektiren projelerde avantaj sağlayabilir. Tenant başına gelir dedicated infrastructure maliyetini karşılayabiliyorsa ekonomik olur. Çok sayıda küçük free-tier kullanıcı için gereksiz pahalı olabilir. Hybrid model bu nedenle farklı segmentlere farklı storage seçeneği sunar.

Database-Per-Tenant Provisioning

Database-per-tenant provisioning yeni müşteri aktivasyonunun tamamen otomatik bir altyapı workflow'u haline gelmesini gerektirir. Database, kullanıcı, credential, migration, seed ve health check adımları tek state machine içinde yönetilebilir. Her adım tekrar çalışmaya dayanıklı olmalıdır. Tenant ancak tüm kontroller tamamlandıktan sonra active state'e geçirilmelidir. Manual database oluşturma süreci tenant sayısı arttığında hem hata hem security drift riskini büyütür.

Yeni Database Oluşturmak

Provisioning orchestrator uygun cluster veya region seçtikten sonra database oluşturur. Naming convention tenant public bilgisini gereksiz sızdırmamalıdır. Database ownership migration role'a atanabilir. Resource tag veya metadata cost attribution için eklenebilir. Creation sonucu tenant directory state'ine kaydedilir.

Database User Oluşturmak

Runtime database user minimum yetkilerle oluşturulmalıdır. DDL yetkisi migration role'de kalabilir. Tenant-specific user kullanılıyorsa naming ve lifecycle tamamen otomatik olmalıdır. Offboarding sırasında user revoke edilir. Permission drift periyodik audit ile kontrol edilebilir.

Credential Üretmek

Güçlü ve random credential provisioning sırasında oluşturulur. Secret hiçbir zaman source code veya log içine yazılmamalıdır. Secret manager güvenli storage noktasıdır. Application credential'ı kısa süreli cache edebilir. Rotation süreci tenant availability'yi bozmadan desteklenmelidir.

Migration Çalıştırmak

Yeni database current schema version'a getirilir. Baseline snapshot provisioning süresini kısaltabilir. Migration failure tenant activation'ını durdurur. Version metadata directory'ye yazılır. Health check schema ve critical query'leri doğrular.

Seed Data

Default role, tenant configuration ve başlangıç verileri otomatik eklenebilir. Seed logic idempotent olmalıdır. Global reference data gerekmedikçe tenant database'e kopyalanmamalıdır. Seed version application release ile uyumlu olmalıdır. Data validation provisioning'in ayrı adımı olabilir.

Connection String Kaydetmek

Tenant directory raw secret yerine secure secret reference veya endpoint metadata saklayabilir. Connection string loglarda görünmemelidir. Endpoint, database name ve secret identifier ayrı alanlar halinde tutulabilir. Region migration sırasında mapping güncellenebilir. Directory change audit edilmelidir.

Health Check

Database oluşturulduktan sonra connection, schema version ve basit read-write işlemleri test edilmelidir. RLS veya permission modeli varsa runtime role ile doğrulama yapılır. Timeout ve network path kontrol edilir. Health check başarısızsa tenant active edilmez. Error provisioning dashboard'a aktarılır.

Tenant'ı Aktif Etmek

Tüm provisioning adımları tamamlandıktan sonra tenant state active yapılır. Application request routing ancak bu aşamadan sonra açılır. Initial admin kullanıcı daveti gönderilebilir. Billing activation aynı state transition ile ilişkilendirilebilir. Activation event downstream sistemlere yayınlanabilir.

Tenant Directory / Control Plane Database

Tenant directory tüm storage modellerinin nerede bulunduğunu ve tenant'ın yaşam döngüsü durumunu takip eden control plane bileşenidir. Shared schema kullanan tenant için shard ID, dedicated tenant için database endpoint ve region tutulabilir. Isolation tier uygulamanın routing kararını etkiler. Directory hızlı ve güvenilir olmalıdır, fakat data plane request'lerinin her seferinde merkezi directory'ye bağımlı olması risk yaratabilir. Replicated cache veya local routing snapshot control plane failure etkisini azaltabilir.

Tenant Metadata

Tenant adı, plan, state ve isolation tier temel metadata'dır. Routing için gerekli olmayan hassas business data directory içinde tutulmamalıdır. Metadata versioning ve audit önemlidir. Tenant state suspended olduğunda application access policy değişebilir. Control plane API bu bilgileri merkezi olarak yönetir.

Database Location

Tenant'ın hangi database veya cluster içinde olduğu mapping halinde tutulur. Hybrid model tenant promotion sırasında bu alanı değiştirir. Routing layer cache kullanabilir. Cutover sırasında eski ve yeni location geçici olarak birlikte tutulabilir. Mapping update atomik olmalıdır.

Schema Location

Schema-per-tenant modelinde tenant schema adı ve database cluster bilgisi directory'de tutulabilir. Schema identifier client tarafından oluşturulmamalıdır. Migration sırasında schema location değişirse application routing güncellenir. Directory lookup cache invalidation doğru yapılmalıdır. Restore sonrası mapping doğrulanmalıdır.

Shard ID

Sharded model tenant'ın hangi shard üzerinde bulunduğunu shard ID ile ifade eder. Query router bu bilgiye göre connection seçer. Rebalancing sırasında shard ID değişir. Old mapping belirli grace period boyunca dual routing için tutulabilir. Monitoring shard capacity ve tenant distribution ile ilişkilendirir.

Region

Data residency gereksinimi tenant region alanıyla yönetilebilir. Provisioning uygun regional cluster seçer. Application request en yakın veya yetkili region'a routing edilir. Cross-region analytics policy bu metadata'yı dikkate almalıdır. Region migration ayrı data movement workflow gerektirir.

Database Endpoint

Endpoint tenant'ın bağlanacağı cluster veya database proxy adresini belirtir. Secret ile ayrı tutulması güvenlidir. Failover durumunda endpoint değişebilir. Application resolver kısa TTL cache kullanabilir. Endpoint update health check ile doğrulanmalıdır.

Tenant State

provisioning, active, suspended ve offboarding gibi state'ler allowed operation'ları belirler. Database route aktif olsa bile suspended tenant request'i application seviyesinde engellenebilir. State transition audit edilmelidir. Failed provisioning ayrı state olabilir. Lifecycle automation bu state machine üzerinden çalışır.

Schema Version

Database veya schema'nın current migration version bilgisi directory'de tutulabilir. Orchestrator hangi tenant'ların target version gerisinde olduğunu görür. Application minimum required version kontrolü yapabilir. Restore sonrası version tekrar doğrulanmalıdır. Drift dashboard operasyon ekibine görünürlük sağlar.

Isolation Tier

Isolation tier tenant'ın pool, schema veya dedicated database modelinde olup olmadığını belirtir. Product subscription ile ilişkilendirilebilir. Routing layer bu alan üzerinden storage adapter seçebilir. Enterprise upgrade tenant promotion workflow tetikleyebilir. Tier değişikliği data migration ve billing koordinasyonu gerektirir.

Control Plane ve Data Plane Ayrımı

Control plane tenant lifecycle, billing, provisioning ve routing metadata'sını yönetirken data plane gerçek tenant business verilerini işler. Bu ayrım büyüyen SaaS sistemlerinde yönetim fonksiyonlarıyla müşteri trafiğini birbirinden izole etmeye yardımcı olur. Control plane outage olduğunda mevcut tenant'ların tamamen hizmet dışı kalmaması hedeflenebilir. Tenant directory bilgisi data plane tarafında cache veya replicated read model olarak tutulabilir. Bu yaklaşım multi-tenant mimariyi daha dayanıklı ve operasyonel olarak daha anlaşılır hale getirir.

Control Plane Nedir?

Control plane sistem kaynaklarının nasıl oluşturulacağını ve yönetileceğini belirler. Tenant registration, provisioning, billing ve lifecycle state burada yönetilir. Normal müşteri business sorguları control plane database'inde çalışmamalıdır. Erişim daha sıkı admin permission'larla sınırlandırılabilir. Audit log tüm state değişikliklerini kaydetmelidir.

Tenant Provisioning

Yeni tenant'ın database, schema, role ve default configuration oluşturma süreci control plane tarafından orkestre edilir. Workflow asenkron olabilir. Her step state machine'e yazılır. Failure retry ve cleanup mekanizması bulunmalıdır. Data plane yalnızca active state'teki tenant'ı kabul eder.

Billing ve Subscription

Subscription tier isolation modelini ve resource quota'yı etkileyebilir. Enterprise upgrade dedicated database provisioning tetikleyebilir. Billing state access suspension kararına girdi olabilir. Finansal data ile application data'nın sahiplik sınırı açık tutulmalıdır. State change event'leri güvenilir event mechanism ile data plane'e yansıtılabilir.

Tenant Directory

Directory control plane'in routing haritasıdır. Tenant ID ile region, shard ve database location ilişkisini tutar. Data plane bu bilgiyi düşük latency ile okuyabilmelidir. Read cache veya replicated store kullanılabilir. Write yetkisi yalnızca control plane workflow'larına verilmelidir.

Data Plane Nedir?

Data plane müşterinin günlük application request'lerini ve business verilerini işler. Projects, orders ve reports gibi tenant-scoped entity'ler burada bulunur. Request tenant context ile doğru storage'a yönlendirilir. Data plane control plane write yetkisine sahip olmamalıdır. Bu ayrım blast radius ve security boundary açısından değerlidir.

Tenant Uygulama Verileri

Tenant'a ait operasyonel data data plane storage içinde tutulur. Shared schema veya dedicated database seçimi isolation tier'e bağlı olabilir. Backup ve restore politikası storage modeline göre uygulanır. Analytics için data warehouse'a güvenli pipeline kurulabilir. Control plane yalnızca routing metadata'sını bilmeli, business data'yı gereksiz yere taşımamalıdır.

Control Plane Arızasının Data Plane'e Etkisini Azaltmak

Her request'te merkezi control plane database lookup yapmak yüksek bağımlılık yaratır. Tenant route cache data plane'e kısa süreli bağımsızlık sağlar. Existing active tenant mapping'leri immutable snapshot olarak tutulabilir. Yeni provisioning veya tier change geçici olarak gecikebilir fakat mevcut trafik devam edebilir. Cache stale davranışı security ve routing açısından açık policy ile sınırlandırılmalıdır.

Database-Per-Tenant Connection Pooling

Database-per-tenant modelinin en önemli ölçek problemlerinden biri connection pool sayısının tenant sayısıyla birlikte büyümesidir. Her tenant için sabit minimum connection ayırmak binlerce idle connection üretebilir. Lazy pool creation ve idle pool eviction bu yükü azaltır. Database proxy veya serverless connection yaklaşımı da connection explosion sorununu hafifletebilir. Pool monitoring tenant ve database seviyesinde connection count, wait time ve error rate göstermelidir.

Pool Per Tenant Problemi

Her tenant için ayrı pool isolation açısından doğal görünür. Fakat yüzlerce tenant için her pool minimum birkaç connection tutarsa database limitleri hızla dolar. Küçük tenant'ların çoğu uzun süre idle olabilir. Pool lazy oluşturulmalı ve idle olduğunda kapatılmalıdır. Connection budget cluster seviyesinde merkezi yönetilmelidir.

Connection Explosion

Tenant ve application instance sayısı çarpıldığında toplam connection sayısı beklenenden çok daha hızlı büyüyebilir. On application pod ve yüz tenant ciddi connection yükü oluşturabilir. Database proxy bu bağlantıları multiplex edebilir. Pool size tenant traffic'e göre dinamik tutulabilir. Capacity planning maksimum concurrent active tenant sayısına göre yapılmalıdır.

Lazy Pool Creation

Application yalnızca tenant için ilk request geldiğinde connection pool oluşturabilir. Böylece hiç trafik almayan tenant kaynak tüketmez. Pool creation latency ilk request'i etkileyebilir. Warm-up yalnızca aktif tenant cohort için uygulanabilir. Creation failure tenant-specific circuit breaker ile yönetilebilir.

Idle Pool Eviction

Belirli süre request almayan tenant pool'u kapatılabilir. Sonraki request yeni pool oluşturur. Eviction threshold traffic pattern'e göre ayarlanmalıdır. Aşırı kısa süre connection churn yaratabilir. Monitoring pool create ve close rate'i göstermelidir.

Connection Proxy

Database proxy application connection'larını daha az backend connection üzerinde toplayabilir. Bu model serverless veya yüksek tenant sayılı sistemlerde değerli olur. Transaction pooling davranışı session state kullanımını sınırlar. Credential ve routing proxy tarafında yönetilebilir. Failure mode ve latency overhead test edilmelidir.

Serverless Database Yaklaşımları

Serverless database altyapıları tenant başına fiziksel kaynak yönetimini farklı biçimde sadeleştirebilir. Connection ve compute elastikliği operasyon yükünü azaltabilir. Buna rağmen logical routing, backup ve schema migration sorumluluğu devam eder. Cost pattern burst workload'da dikkatle izlenmelidir. Provider-specific özelliklere aşırı bağımlılık migration stratejisini etkileyebilir.

Pool Monitoring

Pool size, active connection, wait time ve connection error temel metriklerdir. Tenant veya database ID ile etiketlenmelidir. Connection wait yükseliyorsa pool veya database saturation araştırılmalıdır. Idle pool sayısı maliyet ve resource kullanımını gösterir. Monitoring automation eviction ve capacity policy kararlarına veri sağlar.

Database-Per-Tenant Credential Yönetimi

Database-per-tenant modelinde credential yönetimi izolasyonun önemli parçasıdır. Tenant başına ayrı user ve secret kullanmak bir credential sızıntısının etki alanını sınırlar. Bunun karşılığında yüzlerce secret için rotation, storage ve cache yönetimi gerekir. Secret manager bu süreci merkezi hale getirir. Runtime application yalnızca ihtiyaç duyduğu tenant credential'ına erişebilecek permission yapısıyla tasarlanmalıdır.

Tenant Bazında Credential

Her tenant database için ayrı credential oluşturulabilir. Credential yalnızca ilgili database üzerinde minimum yetkiye sahip olur. Sızıntı tüm tenant verilerine değil tek tenant database'e sınırlanabilir. Tenant offboarding sırasında credential revoke edilir. Secret inventory otomatik olarak lifecycle state ile senkron tutulmalıdır.

Secret Manager

Credential'lar source code, environment file veya tenant directory içinde plain text tutulmamalıdır. Secret manager güvenli storage ve access audit sağlar. Application identity yalnızca gerekli secret path'lerine erişmelidir. Secret fetch latency için kısa süreli cache kullanılabilir. Rotation event cache invalidation ile birlikte tasarlanmalıdır.

Credential Rotation

Credential periyodik veya incident sonrası değiştirilebilmelidir. Zero-downtime rotation için old ve new credential kısa süre birlikte geçerli olabilir. Application cache yeni secret'ı alır. Başarılı connection doğrulandıktan sonra eski credential revoke edilir. Rotation workflow audit edilmelidir.

Uygulamada Credential Cache

Her request'te secret manager çağrısı latency ve maliyet oluşturabilir. Application credential'ı encrypted memory cache içinde kısa süre saklayabilir. Cache key tenant ID veya database ID ile ilişkilendirilebilir. Rotation sonrası TTL veya event invalidation gerekir. Secret loglara veya error mesajına yazılmamalıdır.

Least Privilege Database User

Runtime user yalnızca application'ın ihtiyaç duyduğu CRUD yetkilerini taşımalıdır. Database create, role management ve schema ownership ayrı migration role'de bulunur. RLS veya row policies kullanılıyorsa runtime role bypass yetkisine sahip olmamalıdır. Permission changes infrastructure code ile yönetilebilir. Periyodik permission audit drift'i yakalar.

Credential Leak Etki Alanını Küçültmek

Tek global credential tüm tenant database'lerine erişebiliyorsa leak blast radius çok büyür. Tenant-specific veya cluster-scoped credential bu etkiyi sınırlar. Secret access IAM permission ile ayrıca ayrılabilir. Support ve developer kullanıcıları production secret'lara doğrudan erişmemelidir. Incident response hangi secret'ın hangi tenant'ı etkilediğini hızla belirleyebilmelidir.

Hybrid Multi-Tenant Model

Hybrid multi-tenant model aynı SaaS içinde shared ve dedicated storage seçeneklerini birlikte kullanır. Küçük tenant'lar ortak pool'da tutulurken enterprise, regulated veya çok büyük tenant'lar ayrı database'e taşınabilir. Bu model maliyet ile izolasyon arasında güçlü denge sağlar. Ancak application'ın storage topology'den bağımsız tasarlanması gerekir. Tenant directory, dynamic routing ve data migration tooling hybrid mimarinin temel bileşenleridir.

Shared + Dedicated Database

Standard tenant'lar shared shard üzerinde çalışırken belirli tenant'lar dedicated database kullanabilir. Repository aynı interface üzerinden her iki modele erişebilir. Storage resolver tenant directory'den isolation tier okur. Application business code conditional database logic ile dolmamalıdır. Bu ayrım future migration ve test süreçlerini kolaylaştırır.

Standard Tenant

Standard tenant ortak database pool kullanabilir. Resource quota ve RLS shared model güvenliğini sağlar. Cost efficiency yüksektir. Tenant büyüdüğünde promotion threshold izlenebilir. Upgrade dedicated isolation seçeneği sunabilir.

Enterprise Tenant

Enterprise tenant dedicated database veya dedicated region talep edebilir. Tenant başına gelir bu altyapı maliyetini karşılayabilir. Backup, restore ve maintenance planı tenant'a özel olabilir. SLA ve monitoring daha sıkı uygulanabilir. Isolation tier sözleşmede açıkça tanımlanmalıdır.

Regulated Tenant

Regüle müşteriler data residency, encryption key veya ayrı database gerektirebilir. Hybrid model bu talepleri tüm tenant'lara uygulamadan destekler. Provisioning region ve key policy metadata'sını dikkate alır. Audit ve restore süreçleri tenant-specific olabilir. Compliance requirement product configuration'a dönüştürülebilir.

Büyük Tenant

Shared pool içinde sürekli high CPU veya storage tüketen tenant dedicated storage'a taşınabilir. Bu işlem noisy neighbor etkisini azaltır. Cost attribution promotion kararına veri sağlar. Data migration zero-downtime veya kısa maintenance window ile yapılabilir. Cutover sonrası old shared rows kontrollü biçimde silinir.

Isolation Tier

Isolation tier pool, dedicated database, dedicated region veya tenant-specific key gibi özellikleri bir arada ifade edebilir. Tenant directory bu tier'i routing ve provisioning için kullanır. Billing plan ile ilişkilendirilebilir. Tier upgrade otomatik migration workflow tetikleyebilir. Down-grade senaryosu da veri taşıma ve policy açısından ayrıca tasarlanmalıdır.

Aynı Uygulamanın Farklı Storage Modellerini Desteklemesi

Business service doğrudan belirli database connection'a bağımlı olmamalıdır. Tenant-aware repository storage adapter seçebilir. Shared schema ve dedicated database aynı domain modelini kullanmalıdır. Migration tooling data shape farkı oluşturmamalıdır. Bu abstraction hybrid modelin sürdürülebilirliği açısından en önemli tasarım kararlarından biridir.

Tiered Multi-Tenancy

Tiered multi-tenancy izolasyon ve performans seviyesini ürün paketleriyle ilişkilendirmeyi sağlar. Free kullanıcılar pool modelinde çalışırken enterprise müşteriler dedicated database ve hatta dedicated region alabilir. Bu yaklaşım infrastructure cost ile müşteri değerini hizalar. Tenant upgrade yalnızca billing değişikliği değil, gerekirse storage migration tetikleyen lifecycle olayıdır. Ürün ve platform ekipleri tier geçişinin teknik sınırlarını birlikte tasarlamalıdır.

Free Tier

Free tenant'lar genellikle en yüksek sharing seviyesinde çalışır. Resource quota ve rate limit platform maliyetini kontrol altında tutar. Shared schema ve ortak cache ekonomik çözüm sağlar. Backup ve restore SLA daha sınırlı olabilir. Tenant büyüdüğünde paid plan'a geçiş ölçülebilir hale gelir.

Standard Tier

Standard tier shared infrastructure kullanmaya devam ederken daha yüksek quota ve support sunabilir. Shard distribution tenant boyutuna göre optimize edilebilir. RLS ve tenant-aware constraints isolation sağlar. Dedicated database bu segment için opsiyonel upgrade olabilir. Cost attribution gross margin takibini destekler.

Enterprise Tier

Enterprise müşteriler dedicated database, custom region ve daha sık backup isteyebilir. Support access ve audit requirements daha sıkı olabilir. Migration ve maintenance planı müşteriyle koordineli yapılabilir. Tenant-level restore testleri SLA'nın parçası olabilir. Infrastructure özellikleri product entitlement olarak modellenmelidir.

Pool Model

Pool tier çok sayıda tenant'ı ortak kaynak üzerinde çalıştırır. Cost efficiency yüksektir. Noisy neighbor protection güçlü olmalıdır. Tenant metrics ve promotion threshold izlenmelidir. Büyük tenant gerektiğinde daha üst izolasyon tier'ine taşınabilir.

Dedicated Database

Dedicated database premium isolation özelliği olabilir. Backup, restore ve performance tuning tenant bazında yapılabilir. Operasyon maliyeti daha yüksek olduğu için fiyatlandırmaya yansıtılmalıdır. Provisioning automation olmadan satış sürecini yavaşlatabilir. Health ve migration dashboard tenant-specific görünüm sunmalıdır.

Dedicated Region

Belirli ülke veya region gereksinimi olan tenant için ayrı regional cluster kullanılabilir. Tenant directory routing bu bilgiyi taşır. Data export ve analytics cross-region policy'ye uygun olmalıdır. Region failure DR planı ayrıca test edilmelidir. Dedicated region maliyeti enterprise contract içinde açıkça ele alınmalıdır.

Isolation'ı Ürün Özelliğine Dönüştürmek

Isolation yalnızca backend detayı değil müşteri için güvenlik ve compliance değeri taşıyan özellik olabilir. Dedicated database, BYOK veya regional storage premium plan unsuru haline getirilebilir. Teknik imkanların sözleşmede açık karşılığı olmalıdır. Product marketing ile actual architecture arasında fark oluşmamalıdır. Monitoring müşteriye verilen isolation sözünü doğrulayabilmelidir.

Tenant'ı Shared Database'den Dedicated Database'e Taşımak

Tenant promotion büyüyen SaaS için kritik migration senaryolarından biridir. Shared database'deki tenant verisi yeni dedicated database'e güvenli biçimde taşınır. Data copy sırasında yeni write'ların kaybolmaması için change data capture, dual write veya kısa write freeze kullanılabilir. Verification tamamlandıktan sonra tenant directory routing yeni database'e çevrilir. Rollback planı ve eski veriyi ne zaman silme kararı migration'ın en başında tanımlanmalıdır.

Tenant Promotion

Promotion tenant'ın isolation tier yükseltmesidir. Trigger enterprise upgrade, compliance veya noisy neighbor olabilir. Control plane migration workflow oluşturur. Tenant state geçici olarak migration durumuna alınabilir. Customer communication gerekiyorsa schedule önceden paylaşılır.

Hedef Database Provisioning

Yeni dedicated database tenant region ve policy'ye göre oluşturulur. Current schema version uygulanır. Runtime credential ve backup policy hazırlanır. Health check tamamlanmadan data copy başlamamalıdır. Directory target location'ı pending state olarak saklayabilir.

Data Copy

Historical tenant rows shared database'den hedef database'e kopyalanır. Export query her zaman tenant ID ile scope edilmelidir. Row count ve checksum benzeri validation yapılabilir. File veya object data mapping ayrıca ele alınmalıdır. Copy büyükse chunk ve parallel worker kullanılabilir.

Change Data Capture

Initial copy sırasında source tenant'a yeni write gelmeye devam edebilir. CDC veya event log incremental değişiklikleri hedefe taşır. Ordering ve idempotency önemlidir. Lag metric cutover readiness için izlenir. CDC cross-tenant event taşımadığını doğrulayan testlere sahip olmalıdır.

Verification

Source ve target row count, key business aggregate ve sample query sonuçları karşılaştırılır. Tenant-specific integration tests hedef database üzerinde çalıştırılır. Background job ve file reference'ları kontrol edilir. Verification threshold karşılanmadan cutover yapılmamalıdır. Sonuç audit kaydına yazılabilir.

Dual Read / Dual Write

Bazı sistemler kısa süre source ve target üzerinde paralel read veya write kullanabilir. Bu yöntem migration confidence sağlar fakat consistency mantığını zorlaştırır. Dual write failure reconciliation gerektirir. Mümkün olduğunca kısa tutulmalıdır. Clear source of truth tanımlanmalıdır.

Cutover

Tenant directory routing yeni database'i active location yapar. Cache invalidation tüm application instance'larına ulaşmalıdır. Yeni request'ler hedef storage'a gitmelidir. Cutover anında kısa write pause uygulanabilir. Monitoring error ve latency değerlerini yakından izler.

Rollback

Target database ciddi hata verirse routing source'a döndürülebilir. Rollback mümkün olması için source data belirli süre korunmalıdır. Cutover sonrası write'ların source'a nasıl geri aktarılacağı planlanmalıdır. Dual write veya CDC bu konuda yardımcı olabilir. Rollback deadline açık olmalıdır.

Eski Veriyi Temizlemek

Migration stabil hale geldikten sonra shared database'deki eski tenant rows silinebilir. Retention veya rollback window tamamlanmadan deletion yapılmamalıdır. Delete operasyonu büyükse chunk halinde çalıştırılabilir. Backup retention policy eski verinin nerede kalacağını ayrıca tanımlar. Deletion audit kaydı tutulmalıdır.

Sharded Multi-Tenant Database

Sharding tenant'ları birden fazla database birimine dağıtarak tek database kapasite sınırını aşmayı sağlar. Tenant-based sharding multi-tenant sistemler için doğal bir yaklaşımdır, çünkü aynı tenant'ın verisi mümkün olduğunca tek shard içinde tutulur. Tenant directory shard mapping'i yönetir. Shard kapasitesi ve tenant boyutu düzenli izlenerek rebalancing yapılır. Büyük tenant'ı kendi shard'ına almak noisy neighbor etkisini azaltabilir.

Sharding Nedir?

Sharding veri setini bağımsız database parçalarına yatay olarak böler. Her shard toplam tenant veya satırların bir bölümünü tutar. Application router doğru shard'a request gönderir. Shard failure tüm sistem yerine belirli tenant grubunu etkileyebilir. Cross-shard query ve transaction daha zor hale gelir.

Tenant-Based Sharding

Tenant-based sharding aynı tenant'ın tüm verisini belirli shard'a yerleştirir. Bu yöntem tenant-scoped transaction ve query'leri local tutar. Directory mapping tenant ID'den shard'a yönlendirir. Tenant migration shard rebalancing için temel operasyondur. Cross-tenant analytics ayrı warehouse üzerinden yürütülebilir.

Shard Key Olarak tenant_id

tenant_id doğal shard key olabilir. Hash veya directory-based mapping kullanılabilir. Tenant boyutları eşit değilse yalnızca hash dağılımı hot shard yaratabilir. Büyük tenant special placement gerektirebilir. Shard key ileride değişmesi zor bir karardır.

Hash Sharding

Tenant ID hash sonucu belirli shard'a atanabilir. Yeni tenant dağılımı otomatik ve dengeli olabilir. Ancak shard sayısını değiştirmek birçok tenant'ın yeniden yerleşmesini gerektirebilir. Consistent hashing bu hareketi azaltabilir. Directory override büyük tenant'ları özel shard'a yönlendirebilir.

Range Sharding

Tenant ID veya başka bir sıralı alan belirli aralıklara göre shard edilir. Routing anlaşılırdır. Fakat yeni tenant ID'ler belirli shard'a yığılıyorsa dağılım dengesiz olabilir. Tenant büyüklüğü aralıklarla korelasyon göstermeyebilir. Rebalancing planı gereklidir.

Tenant Directory ile Shard Routing

Directory-based sharding tenant'ın shard ID'sini explicit olarak saklar. Tenant istediğiniz shard'a taşınabilir. Hash function değişikliği gerekmez. Routing lookup maliyeti cache ile azaltılabilir. Rebalancing sonunda directory mapping atomik güncellenmelidir.

Shard Sayısı

Başlangıçta gereğinden fazla shard operasyon maliyetini artırır. Çok az shard ise gelecekte büyük rebalancing gerektirebilir. Capacity, growth ve failure domain birlikte değerlendirilmelidir. Empty shard reserve expansion için faydalı olabilir. Monitoring shard başına tenant, storage ve QPS gösterir.

Shard Rebalancing

Hot veya dolu shard'dan bazı tenant'lar daha boş shard'a taşınır. Data copy ve incremental sync gerekir. Cutover tenant directory update ile yapılır. Tenant migration tooling bu operasyonu standardize etmelidir. Rebalancing sonrası kaynak dağılımı tekrar ölçülmelidir.

Shard İçinde Shared Schema Kullanmak

Birçok SaaS için pratik ölçek modeli, her shard içinde shared schema kullanmaktır. Böylece tek database yerine tenant grupları farklı shard'lara dağıtılır fakat her shard kendi içinde aynı tablo modelini kullanır. Tenant-first index ve RLS yaklaşımı shard içinde devam eder. Shard kapasitesi tenant boyutu ve workload'a göre yönetilir. Cross-shard analytics ve tenant rebalancing için directory ve data movement tooling gereklidir.

Tenant Grupları

Her shard belirli tenant grubunu barındırır. Gruplama hash veya capacity-aware placement ile yapılabilir. Aynı organization'a bağlı related tenant'ları aynı shard'a koymak bazı query ihtiyaçlarını kolaylaştırabilir. Ancak correlated growth hot shard yaratabilir. Placement policy ölçülebilir olmalıdır.

Shard Başına Tenant Sayısı

Tenant sayısı tek başına capacity ölçüsü değildir. Yüz küçük tenant bir büyük tenant'tan daha az kaynak tüketebilir. Storage, QPS ve CPU birlikte değerlendirilmelidir. Soft capacity threshold rebalancing için trigger olabilir. Yeni tenant provisioning en uygun shard'ı seçebilir.

Tenant-First Indexing

Shard içinde shared schema query'leri yine tenant ID üzerinden scope edilir. Composite index tasarımı aynı prensiplere göre yapılır. Daha küçük shard index boyutunu ve vacuum yükünü azaltabilir. En büyük tenant query plan'ı yine izlenmelidir. Global shard admin query'leri için ayrı index gerekebilir.

Shard Capacity

Capacity storage, CPU, I/O, connection ve backup süresi açısından izlenmelidir. Tek metric üzerinden karar verilmemelidir. Growth trend future exhaustion tahmini sağlar. Rebalancing çok geç başlatılırsa emergency migration riski oluşur. Capacity reserve planlı maintenance için alan bırakır.

Büyük Tenant'ı Ayrı Shard'a Taşımak

Büyük tenant shared shard içindeki diğer tenant'ları etkiliyorsa dedicated shard'a taşınabilir. Bu hybrid isolation'ın bir formudur. Tenant migration aynı data copy ve cutover mekanizmasını kullanır. Dedicated shard tamamen ayrı database instance olmak zorunda değildir. Cost ve SLO etkisi migration sonrası karşılaştırılmalıdır.

Cross-Shard Query Problemi

Platform analytics için tüm shard'ları aynı anda query etmek pahalı ve kırılgan olabilir. Fan-out query latency en yavaş shard'a bağlıdır. OLTP shard'ları ağır analytics yüküyle zorlanmamalıdır. Data warehouse veya event streaming daha uygun çözüm olabilir. Cross-shard transactional operation mümkün olduğunca tasarımdan çıkarılmalıdır.

Tenant Rebalancing Nasıl Yapılır?

Tenant rebalancing kapasitesi dolan veya hot hale gelen shard'dan tenant'ı başka shard'a taşıma sürecidir. Hot shard tespiti yalnızca storage değil CPU, latency ve I/O metriklerine dayanmalıdır. Yeni shard hazırlandıktan sonra historical data kopyalanır ve incremental değişiklikler senkronize edilir. Tenant directory cutover anında yeni shard mapping'ine geçirilir. Rollback ve post-migration monitoring planı sürecin ayrılmaz parçasıdır.

Hot Shard Tespiti

Shard latency, CPU, I/O ve connection wait eşikleri izlenmelidir. Global cluster ortalaması problemi gizleyebilir. Tenant attribution hangi müşterilerin load'a katkı verdiğini gösterir. Growth trend proactive rebalancing sağlar. Sadece incident sonrası taşıma yapmak daha risklidir.

Tenant Boyutu

Tenant storage ve request hacmi migration adaylığını etkiler. Büyük tenant'ın transfer süresi daha uzun olur. Row count yanında object storage ve search index boyutu da değerlendirilmelidir. Expected future growth placement kararına dahil edilmelidir. Cost attribution tenant'ın dedicated shard'a geçmesini destekleyebilir.

Yeni Shard

Hedef shard yeterli capacity ve doğru schema version'a sahip olmalıdır. Health ve replication doğrulanmalıdır. Tenant routing öncesinde gerekli index ve configuration hazır olmalıdır. Backup policy aktif edilmelidir. Hedef region data residency kuralıyla uyumlu olmalıdır.

Tenant Verisini Kopyalamak

Source shard'daki yalnızca ilgili tenant satırları güvenli query ile export edilir. Copy chunk'lar halinde yapılabilir. Primary key ve foreign key integrity korunmalıdır. CDC incremental değişiklikleri yakalar. Row count ve checksum doğrulaması yapılır.

Routing Güncellemek

Tenant directory target shard mapping'ini active hale getirir. Application cache'leri invalidate edilir. Old route belirli grace period boyunca fallback için tutulabilir. Yeni request'ler hedef shard'a gitmelidir. Update distributed environment'da atomik davranmalıdır.

Cutover

Incremental lag sıfıra yaklaştığında kısa write pause uygulanabilir. Son delta target'a aktarılır. Routing değiştirilir. Smoke tests kritik business query'leri doğrular. Monitoring hemen sonrasında yükseltilmiş hassasiyetle çalışmalıdır.

Rollback

Target sorun çıkarırsa routing source shard'a geri dönebilir. Cutover sonrası write'ların source'a nasıl yansıtılacağı planlanmalıdır. Rollback window sınırlı tutulmalıdır. Source data migration stabil hale gelene kadar korunur. Rollback olayı audit ve incident review'a kaydedilir.

Rebalance Sonrası Monitoring

Source shard resource kullanımının düştüğü doğrulanmalıdır. Target shard latency ve error rate normal olmalıdır. Tenant SLO migration öncesiyle karşılaştırılır. Connection ve cache behavior izlenir. Old data cleanup ancak gözlem dönemi tamamlandıktan sonra yapılır.

Partitioning ile Multi-Tenancy Arasındaki Fark

Partitioning bir tabloyu fiziksel olarak daha küçük parçalara ayıran database performans ve bakım tekniğidir. Multi-tenancy ise tenant verisini güvenli ve mantıksal biçimde ayırma problemidir. tenant_id partition key olarak kullanılabilir fakat partitioning tek başına authorization veya isolation sağlamaz. RLS ve application tenant scoping yine gereklidir. Partitioning doğru query pruning ve maintenance avantajı sağlamak için kullanılmalıdır, güvenlik mekanizması olarak değil.

Database Isolation

Database isolation tenant verisinin hangi fiziksel veya logical boundary içinde tutulduğunu ifade eder. Shared schema, separate schema ve dedicated database farklı seviyeler sunar. Partition bu boundary ile aynı kavram değildir. Aynı partition içinde birden fazla tenant bulunabilir. Security policy ayrıca uygulanmalıdır.

Table Partitioning

Partitioning büyük table'ı birden fazla child partition'a böler. Query planner uygun partition'ları prune edebilir. Maintenance ve data retention kolaylaşabilir. Partition sayısı aşırı büyürse planning overhead oluşabilir. Tenant modeliyle birlikte kapasite testleri yapılmalıdır.

tenant_id Partition Key

Tenant ID hash partition key olarak kullanılabilir. Tenant satırları belirli partition'a yönlenir. Çok sayıda tenant için tenant başına partition oluşturmak çoğu durumda pratik değildir. Hash partition sınırlı sayıda bucket kullanabilir. RLS yine satır erişimini kontrol etmelidir.

Hash Partitioning

Hash partition tenant ID değerini dengeli bucket'lara dağıtabilir. Large shared table bakımını kolaylaştırabilir. Tenant büyüklükleri çok dengesizse bucket load eşit olmayabilir. Repartitioning maliyetli olabilir. Sharding ile partitioning arasındaki failure domain farkı açıkça anlaşılmalıdır.

Range Partitioning

Range partition çoğunlukla tarih veya sıralı key üzerinden bölme için kullanılır. Multi-tenant event table'larında zaman bazlı retention kolaylaştırabilir. Tenant query'si tarih filtresi olmadan çok partition tarayabilir. Composite partition strategy gerekebilir. Partition plan gerçek query workload ile test edilmelidir.

Partitioning'in RLS Yerine Geçmemesi

Partition hangi satırın nerede saklandığını belirler, kimin görebileceğini değil. Yanlış query başka tenant partition'ındaki satırı okuyabilir. RLS veya authorization yine gereklidir. Partition boundary security boundary olarak kabul edilmemelidir. Cross-tenant leak testleri partitioned table'larda da çalıştırılmalıdır.

Partitioning'in Performans İçin Kullanılması

Partition pruning büyük table scan maliyetini azaltabilir. Vacuum ve retention işlemleri daha yönetilebilir hale gelir. Time-series tenant data için özellikle faydalı olabilir. Ancak gereksiz partition sayısı metadata ve planning maliyetini artırır. Önce gerçek performance bottleneck ölçülmelidir.

Cache Katmanında Tenant İzolasyonu

Database tenant isolation doğru olsa bile cache anahtarları tenant-aware değilse cross-tenant veri sızıntısı oluşabilir. Redis veya benzeri shared cache sistemlerinde her tenant-scoped key açık tenant prefix'i taşımalıdır. Resource ID global unique olsa bile tenant ID eklemek güvenli ve anlaşılır bir convention sağlar. Cache invalidation tenant sınırına göre yapılmalıdır. Dedicated cache yalnızca yüksek trafik veya compliance gerektiren tenant'larda gerekebilir.

Redis

Redis shared cache, session veya rate limit storage için kullanılabilir. Multi-tenant sistemde key namespace tasarımı temel güvenlik konusudur. Tenant ID key'in açık bir parçası olmalıdır. Admin scan veya bulk delete operasyonları güvenli pattern kullanmalıdır. Cache metric'leri tenant workload'u gösterebilir.

Cache Key Prefix

Standart prefix formatı developer hatalarını azaltır. Örneğin tenant:{tenant_id}:... biçimi tüm tenant-scoped key'lerde zorunlu olabilir. Helper library key generation'ı merkezi hale getirir. Raw cache key kullanımını sınırlandırmak faydalıdır. CI testleri Tenant A ve Tenant B için aynı resource ID'nin farklı key ürettiğini doğrulayabilir.

tenant:{id}:resource:{id}

Bu format tenant scope ile resource identity'yi açıkça birleştirir. Debug sırasında key'in kime ait olduğu anlaşılır. Tenant-wide eviction prefix üzerinden yapılabilir. Public tenant ID yerine internal immutable ID kullanmak daha güvenli olabilir. Key length ve serialization performansı ayrıca değerlendirilmelidir.

Cache Poisoning

Yanlış veya saldırgan controlled input cache key oluşturmayı etkilerse başka request'lerin response'u kirlenebilir. Key generation allowlist ve canonicalization kullanmalıdır. Tenant ID trusted context'ten gelmelidir. Cache content doğrulama ve short TTL bazı riskleri azaltabilir. Error ve auth response'ları yanlış şekilde public cache'e alınmamalıdır.

Cross-Tenant Cache Leak

En tipik hata resource ID'yi tek başına cache key yapmaktır. Tenant A project:42 cache'e yazarsa Tenant B aynı key'i okuyabilir. Tenant prefix bu collision'ı önler. Test aynı ID değerini iki tenant fixture'ında kullanmalıdır. Cache hit path database RLS tarafından korunmadığı için özellikle önemlidir.

Tenant Bazlı Cache Eviction

Offboarding veya büyük configuration change sırasında tenant'ın cache kayıtları topluca silinmek isteyebilir. Prefix-based key namespace bunu kolaylaştırır. Büyük key sayısı için scan tabanlı eviction dikkatli yapılmalıdır. Versioned cache namespace daha ölçeklenebilir olabilir. Eviction başka tenant key'lerini etkilememelidir.

Dedicated Cache Gerektiren Tenant'lar

Çok yüksek cache memory veya throughput tüketen enterprise tenant shared cache'i etkileyebilir. Dedicated cache instance veya logical cluster noisy neighbor riskini azaltabilir. Compliance gereksinimi de ayrı cache gerektirebilir. Routing isolation tier üzerinden yapılabilir. Maliyet product pricing'e yansıtılmalıdır.

Search Sistemlerinde Tenant İzolasyonu

Search altyapısı database kadar dikkatli tenant scoping gerektirir. Shared index kullanılıyorsa her document tenant field taşımalı ve tüm search query'leri trusted tenant filter ile çalışmalıdır. Index-per-tenant daha güçlü ayrım sunabilir fakat tenant sayısı arttıkça index yönetimi pahalı hale gelir. Search cache de tenant-aware olmalıdır. Cross-tenant leak testleri doğrudan search query, autocomplete ve aggregation endpoint'lerini kapsamalıdır.

Elasticsearch

Elasticsearch benzeri search motorları tenant field üzerinden shared index modeli destekleyebilir. Query filter application tarafından merkezi şekilde eklenmelidir. Document indexing sırasında tenant ID trusted event context'ten alınmalıdır. Search template tenant filtresini zorunlu hale getirebilir. Cross-tenant aggregation testleri ayrıca yapılmalıdır.

OpenSearch

OpenSearch kullanımında aynı tenancy prensipleri geçerlidir. Shared index, index-per-tenant veya tenant grouping seçenekleri bulunabilir. Role-based document filtering tek başına product authorization yerine geçmemelidir. Index lifecycle ve shard sayısı tenant modelini etkiler. Search telemetry tenant query latency ve index size gösterebilir.

Shared Index

Shared index çok sayıda küçük tenant için resource verimliliği sağlar. Her document tenant_id field içerir. Query filter zorunlu ve merkezi olmalıdır. Cache key tenant context'i taşımalıdır. Büyük tenant noisy neighbor olduğunda ayrı index'e taşınabilir.

Index Per Tenant

Tenant başına index namespace izolasyonunu güçlendirir. Tenant-level deletion ve restore bazı durumlarda kolaylaşır. Ancak binlerce küçük index cluster metadata ve shard overhead yaratabilir. Index lifecycle automation gerekir. Büyük enterprise tenant için daha uygun olabilir.

Tenant Field

Shared index document'larında tenant field immutable ownership bilgisi olmalıdır. Client input'tan doğrudan güvenilmemelidir. Ingestion worker trusted tenant context'i event envelope'dan doğrular. Search query bu field üzerinden filter uygular. Mapping field type tüm index'lerde tutarlı olmalıdır.

Filtered Queries

Her search query tenant filter ile birleştirilmelidir. User query syntax tenant filter'ı override edememelidir. Aggregation ve suggestion API'leri aynı scope'u kullanmalıdır. Search abstraction helper filtreyi otomatik ekleyebilir. Security test filter removal senaryosunu değerlendirmelidir.

Search Cache

Search result cache key query kadar tenant ID de içermelidir. Aynı search text farklı tenant'larda farklı sonuç üretir. Shared cache yanlış tasarlanırsa database dışında doğrudan data leak oluşabilir. Tenant-aware namespace kullanılmalıdır. Cache invalidation document update event'leriyle senkron olabilir.

Cross-Tenant Search Leak Testleri

Tenant A'ya ait benzersiz kelimeler fixture olarak indexlenebilir. Tenant B search query'si bu kelimeyi aradığında sonuç boş olmalıdır. Aggregation, suggestion ve export endpoint'leri de test edilmelidir. Index-per-tenant routing hataları ayrıca denenmelidir. Bu testler CI veya staging security suite içinde düzenli çalışmalıdır.

Object Storage'da Tenant İzolasyonu

Dosya ve object storage multi-tenant sistemlerde database dışındaki en önemli veri sınırlarından biridir. Shared bucket kullanılıyorsa tenant prefix ve access policy birlikte tasarlanmalıdır. Signed URL yalnızca doğrulanmış tenant resource için oluşturulmalıdır. Bucket-per-tenant daha güçlü ayrım sağlayabilir fakat bucket sayısı ve provisioning maliyetini artırır. File download endpoint'i resource ownership kontrolünü database ile senkron biçimde uygulamalıdır.

Shared Bucket

Bir bucket içinde tüm tenant dosyaları tutulabilir. Object key tenant namespace ile başlamalıdır. Application service signed URL üretmeden önce membership ve resource ownership kontrolü yapar. Bucket policy application identity'ye gerekli minimum erişimi vermelidir. Cross-tenant listing mümkünse engellenmelidir.

Tenant Prefix

tenant/{id}/... biçimindeki prefix dosyaları logical olarak ayırır. Offboarding sırasında tenant object'lerini bulmayı kolaylaştırır. Internal immutable tenant ID kullanılması tercih edilebilir. Prefix security boundary tek başına yeterli değildir. IAM veya application access policy ile desteklenmelidir.

Bucket Per Tenant

Enterprise tenant için ayrı bucket daha belirgin isolation ve lifecycle policy sağlar. Encryption key veya region tenant'a özel olabilir. Provisioning ve deletion otomasyonu gerekir. Çok sayıda tenant için bucket limitleri ve management overhead değerlendirilmelidir. Hybrid model yalnızca premium tenant'lara bu seçeneği sunabilir.

Object Key Tasarımı

Object key tahmin edilebilir olsa bile authorization sağlanmış olmalıdır. Tenant ID, resource type ve immutable file ID kullanmak düzenli namespace oluşturur. User filename doğrudan key olarak kullanılmamalıdır. Path traversal benzeri input sorunları normalize edilmelidir. Metadata içinde tenant ID ayrıca saklanabilir.

Signed URL

Signed URL belirli object'e sınırlı süreli erişim sağlar. URL oluşturulmadan önce user'ın active tenant ve resource permission'ı doğrulanmalıdır. Expiration kısa tutulabilir. URL başka tenant object'ine client tarafından dönüştürülememelidir. Audit log signed URL generation olayını kaydedebilir.

Access Policy

Storage access policy application role'ünün gereksiz global yetkilerini sınırlandırmalıdır. Tenant-specific credential kullanılıyorsa prefix veya bucket scope uygulanabilir. Support user doğrudan storage console erişimine sahip olmamalıdır. Administrative access audit edilmelidir. Policy changes infrastructure-as-code üzerinden review edilebilir.

Cross-Tenant File Access

Test Tenant A dosya ID'sini Tenant B session ile download etmeyi denemelidir. Resource ID global unique olsa bile access reddedilmelidir. Signed URL generation endpoint'i ayrıca test edilmelidir. CDN cache key tenant-private content'i public biçimde paylaşmamalıdır. File deletion ve export flow'ları aynı tenant scope'u korumalıdır.

Background Job'larda Tenant İzolasyonu

Background worker'lar HTTP request context dışında çalıştığı için tenant bilgisi kolayca kaybolabilir. Queue message trusted tenant ID ve gerekli actor metadata'sını taşımalıdır. Worker job'ı işleme başlamadan tenant state ve authorization gereksinimini doğrulamalıdır. Database connection veya repository doğru tenant scope ile oluşturulmalıdır. Retry ve dead letter queue süreçleri başka tenant'ın context'ini yanlışlıkla kullanmayacak biçimde tasarlanmalıdır.

Queue Message İçinde Tenant Context

Job message tenant ID'yi açık bir metadata alanında taşımalıdır. Payload'ın business alanı ile security context ayrılmalıdır. Message producer tenant ID'yi trusted request context'ten eklemelidir. Consumer input validation yapmalıdır. Event schema version tenant field'i zorunlu tutabilir.

Trusted Tenant ID

Tenant ID client'ın gönderdiği raw job payload'dan alınmamalıdır. Producer authenticated context veya control plane state üzerinden değeri belirler. Internal event bus message integrity mekanizması kullanılabilir. Consumer tenant directory'den state doğrulayabilir. Unknown tenant message güvenli biçimde fail etmelidir.

Worker Tenant Scope

Worker her job için isolated tenant context oluşturmalıdır. Global mutable variable kullanılmamalıdır. Concurrent job'larda context karışması ciddi veri sızıntısı yaratabilir. Dependency injection veya async-local context kontrollü kullanılabilir. Property-based tests random tenant job sequence çalıştırabilir.

Database Connection

Worker shared schema kullanıyorsa repository tenant ID ile scope edilir ve RLS context set edilir. Dedicated database modelinde correct connection resolver kullanılır. Connection pooling state leakage burada da geçerlidir. Long-running job transaction'ları gereksiz uzun tutulmamalıdır. Job retry yeni connection ve tenant context oluşturmalıdır.

Retry

Retry message aynı tenant context'i korumalıdır. Error handler tenant ID'yi log metadata'sında taşımalıdır. Retry queue routing başka tenant queue'suna karışmamalıdır. Idempotency tenant scope ile birlikte düşünülmelidir. Aynı external ID farklı tenant'larda ayrı operation olabilir.

Dead Letter Queue

Sürekli başarısız job'lar dead letter queue'ya alınabilir. Mesaj tenant ID ve error metadata'sını korumalıdır. Support tool sadece yetkili personelin payload'a erişmesini sağlamalıdır. Replay sırasında tenant state yeniden doğrulanmalıdır. DLQ export hassas tenant verisi içerebilir ve access policy gerektirir.

Cross-Tenant Worker Hataları

Global cache veya mutable context worker'larda en riskli kaynaklardan biridir. Tenant A job'ından kalan state Tenant B işlemine taşınabilir. Test worker pool içinde karışık tenant mesajları paralel çalıştırmalıdır. Database ve cache sonuçları tenant fixture'larıyla doğrulanmalıdır. Worker framework upgrade'leri sonrası isolation regression testleri tekrarlanmalıdır.

Scheduled Job'larda Tenant İzolasyonu

Scheduled job'lar tüm tenant'lar üzerinde periyodik işlem yapabildiği için cross-tenant riskleri taşır. Global cron tenant listesini güvenilir directory'den almalı ve her tenant için ayrı scoped execution başlatmalıdır. Bir tenant'ın hatası tüm batch'i durdurmamalıdır. Job timeout, lease ve retry tenant bazında yönetilmelidir. Tenant sayısı büyüdükçe iteration workload queue'ya bölünerek kontrollü concurrency sağlanabilir.

Global Cron

Global cron tüm active tenant'lar için günlük veya periyodik işi başlatabilir. Cron process doğrudan her tenant database'inde uzun işlem yapmak yerine job enqueue edebilir. Tenant listesi control plane'den alınır. Suspended veya offboarding tenant policy'ye göre atlanabilir. Scheduler failure duplicate job üretmemelidir.

Tenant Bazlı Job

Her tenant için ayrı job oluşturmak failure isolation sağlar. Tenant ID job metadata'sında bulunur. Worker normal tenant-scoped repository ile çalışır. Metric tenant execution süresini ve sonucunu gösterir. Büyük tenant job'u ayrı queue veya daha uzun timeout alabilir.

Tenant Iteration

Binlerce tenant'ı tek process loop içinde işlemek uzun süreli ve kırılgan olabilir. Pagination ile directory tenant listesi okunabilir. Her batch queue'ya dağıtılabilir. Scheduler restart sonrası kaldığı noktayı güvenli biçimde devam ettirebilir. Tenant iteration state persistent tutulabilir.

Job Lease

Distributed scheduler aynı tenant job'unu iki worker'ın aynı anda almaması için lease kullanabilir. Lease tenant ve job type'a göre keylenir. Expiration worker crash durumunda recovery sağlar. Duplicate execution yine idempotent business logic ile güvenli hale getirilmelidir. Lease storage tenant isolation'dan bağımsız global coordination kaynağı olabilir.

Job Timeout

Bir tenant'ın job'u sonsuza kadar çalışmamalıdır. Timeout kaynak tüketimini sınırlar. Büyük tenant için farklı limit gerekebilir. Timeout sonrası partial progress checkpoint ile devam edilebilir. Retry policy diğer tenant job'larının queue'da beklemesini engellemelidir.

Bir Tenant'ın Hatasının Diğerlerini Etkilememesi

Scheduler her tenant execution'ını bağımsız failure domain olarak değerlendirmelidir. Tenant A'daki corrupt data yüzünden Tenant B job'u atlanmamalıdır. Error summary global dashboard'a yazılır. Problemli tenant DLQ veya manual review listesine alınır. Toplam başarı oranı kadar tenant-specific failure metric'i de izlenmelidir.

Multi-Tenant Authentication ve Authorization

Multi-tenant authentication kullanıcının kimliğini doğrularken authorization bu kullanıcının hangi tenant içinde hangi işlemleri yapabileceğini belirler. Tenant membership ve active tenant seçimi bu iki katman arasında bulunur. Bir kullanıcı birden fazla tenant'a üye olabilir ve her tenant içinde farklı role sahip olabilir. RLS tenant sınırını korurken RBAC business permission seviyesini yönetir. Bu ayrımlar net kurulmadığında hem kod hem güvenlik policy'si anlaşılması zor hale gelir.

Authentication

Authentication user veya service account identity'yi doğrular. Password, SSO, token veya API key kullanılabilir. Authentication sonucu global user ID üretir. Tenant access henüz otomatik olarak verilmiş sayılmaz. Sonraki adım membership ve active tenant doğrulamasıdır.

Tenant Membership

Membership user ile tenant arasındaki ilişkiyi temsil eder. State active, invited veya suspended olabilir. Role veya permission set bu kayıtla ilişkilendirilebilir. Her tenant switch sırasında membership kontrol edilmelidir. Revoked membership token cache nedeniyle uzun süre geçerli kalmamalıdır.

Active Tenant

User session belirli anda hangi tenant adına işlem yaptığını bilmelidir. Active tenant UI seçiminden veya API credential'dan belirlenebilir. Server seçim ile membership'i doğrular. Tenant context request boyunca immutable kalmalıdır. Cross-tenant action özel admin workflow olmadan yapılamamalıdır.

RBAC

Role-Based Access Control tenant içindeki yetki gruplarını tanımlar. Admin, editor ve viewer gibi roller kullanılabilir. Role assignment tenant membership'e bağlı olmalıdır. Aynı user farklı tenant'larda farklı role sahip olabilir. Database RLS yalnızca tenant sınırı sağlıyor diye RBAC ihtiyacı ortadan kalkmaz.

Permission

Fine-grained permission belirli resource veya action seviyesinde yetki sağlayabilir. Role'ler permission set'lerine dönüşebilir. Authorization service active tenant ve actor bilgisiyle karar verir. Permission cache tenant ID ile keylenmelidir. Admin bypass davranışı audit edilmelidir.

Tenant Isolation ile RBAC Arasındaki Fark

Tenant isolation başka müşterinin verisine geçişi engeller. RBAC ise doğru tenant içinde kullanıcının hangi işi yapabileceğini belirler. Viewer Tenant A verisini görebilir fakat silemeyebilir. RLS yalnızca tenant ID filtresi uygularsa delete permission'ı bilmez. Bu nedenle iki katman farklı sorumluluklara sahiptir.

Bir Kullanıcının Birden Fazla Tenant'a Üye Olması

B2B SaaS'ta danışman veya agency kullanıcısı birden fazla organization'a üye olabilir. Membership join table bu modeli destekler. Active tenant seçimi açık kullanıcı deneyimiyle yapılmalıdır. Session switch sırasında eski tenant cache veya context'i temizlenmelidir. Audit log hangi tenant altında işlem yapıldığını kaydetmelidir.

Support ve Admin Kullanıcıları Nasıl Tasarlanmalı?

Platform support ve admin erişimi normal tenant kullanıcı erişiminden ayrı güvenlik modeli gerektirir. Support personelin tüm tenant verisini sürekli görebilmesi risklidir. Just-in-time access, approval, time limit ve audit ile kontrollü erişim daha güvenli yaklaşım sağlar. Impersonation kullanıcı deneyimini debug etmek için yararlı olabilir fakat açık banner ve log gerektirir. Cross-tenant admin capability mümkün olduğunca özel admin API ve düşük yetkili read-only araçlar üzerinden yürütülmelidir.

Platform Admin

Platform admin tenant lifecycle ve infrastructure yönetebilir. Normal customer data'ya sınırsız erişim otomatik verilmemelidir. Permission alanları provisioning, billing ve support olarak ayrılabilir. Elevated action MFA veya approval gerektirebilir. Tüm admin işlemleri audit edilmelidir.

Tenant Admin

Tenant admin yalnızca kendi organization sınırı içinde yüksek yetkiye sahiptir. User invitation, role ve configuration yönetebilir. Platform-level tenant değişikliklerine erişemez. RLS tenant isolation'ı korur. Tenant admin audit log kendi organization'ı için erişilebilir olabilir.

Support User

Support user müşteri sorunlarını çözmek için sınırlı veri erişimine ihtiyaç duyabilir. Default access no-data olabilir. Ticket veya approval üzerinden tenant-specific temporary access açılabilir. Sensitive fields maskelenebilir. Session sona erdiğinde access otomatik kaldırılmalıdır.

Impersonation

Impersonation support personelin kullanıcı deneyimini belirli tenant içinde görmesini sağlar. Gerçek kullanıcının credential'ını kullanmak yerine controlled support session oluşturulmalıdır. UI açıkça impersonation durumunu göstermelidir. Write action'lar sınırlandırılabilir. Audit log gerçek support actor ve impersonated user'ı birlikte kaydetmelidir.

Just-in-Time Support Access

Support access yalnızca ihtiyaç olduğunda ve belirli süre için açılır. Ticket ID ve reason zorunlu metadata olabilir. Approval role veya customer consent policy'ye bağlı olabilir. Time window tamamlandığında permission otomatik revoke edilir. Bu model permanent broad support privilege riskini azaltır.

Approval

Hassas tenant veya regulated customer için support access ikinci kişi onayı gerektirebilir. Approval trail audit edilir. Emergency break-glass süreci ayrı tanımlanmalıdır. Approver aynı action'ı gerçekleştiren kişi olmamalıdır. Policy enterprise contract'a göre farklılaştırılabilir.

Audit Log

Support access başlangıç, bitiş ve tüm kritik actions audit log'da bulunmalıdır. Tenant, support actor ve reason saklanmalıdır. Log değiştirilemez veya ayrı güvenli storage'da tutulabilir. Customer-facing audit seçeneği enterprise feature olabilir. Privacy gereği hassas payload tamamı loglanmamalıdır.

Support Erişiminin Süresini Sınırlandırmak

Permanent support access zamanla gereksiz privilege accumulation oluşturur. TTL ile access otomatik kapanmalıdır. Aktif support session uzatılacaksa yeni approval gerekebilir. Idle timeout ayrıca uygulanabilir. Access expiration event'i monitoring ve audit sistemine yazılmalıdır.

Cross-Tenant Admin Sorguları

Platform reporting veya support bazı durumlarda birden fazla tenant verisini görmeye ihtiyaç duyabilir. Bu sorgular normal application runtime role üzerinden yapılmamalıdır. Ayrı reporting role, read-only replica veya özel admin API daha güvenli sınırlar sağlar. Sensitive fields maskelenmeli ve tüm erişimler audit edilmelidir. RLS bypass yetkisi yalnızca gerekli servis veya role ile sınırlı tutulmalıdır.

Normal Application Role'den Ayırmak

Application role tenant-scoped query için tasarlanmalıdır. Aynı role'e “bazen tüm tenant'ları gör” yetkisi eklemek güvenlik modelini zayıflatır. Cross-tenant erişim ayrı credential ve code path kullanmalıdır. Bu separation accidental bypass riskini azaltır. Audit hangi role ile query çalıştığını göstermelidir.

Reporting Role

Reporting role read-only ve cross-tenant erişim için özel oluşturulabilir. Production OLTP primary yerine replica veya warehouse kullanması tercih edilebilir. Sensitive column permission'ları sınırlandırılabilir. Credential yalnızca reporting service identity tarafından kullanılmalıdır. Query usage monitoring yapılmalıdır.

Admin API

Admin API cross-tenant işlemleri açık endpoint setiyle sınırlandırır. Normal customer API'den ayrı authentication policy uygulanabilir. MFA, approval veya network restriction eklenebilir. Her action reason ve actor ile audit edilir. Generic arbitrary SQL yetkisi vermekten çok daha güvenlidir.

Read-Only Access

Çoğu support ve analytics ihtiyacı write yetkisi gerektirmez. Read-only role blast radius'u azaltır. Transaction read-only mode ek güvence sağlayabilir. Export gibi büyük query'ler resource limitine tabi olmalıdır. Write gerektiren admin operasyonlar ayrı workflow üzerinden yürütülmelidir.

Audit

Cross-tenant query actor, purpose ve tenant scope bilgisiyle loglanmalıdır. Geniş query'ler özel alert üretebilir. Audit log regular review'a tabi tutulabilir. Customer contract gerektiriyorsa erişim raporu üretilebilir. Sensitive data access pattern'i security monitoring'e entegre edilebilir.

Sensitive Field Masking

Support veya analytics kullanıcısı tüm alanlara ihtiyaç duymayabilir. Email, phone veya secret benzeri alanlar maskelenebilir. Database view veya application serialization üzerinden uygulanabilir. Mask bypass yalnızca özel permission ile verilmelidir. Masking policy tenant compliance tier'e göre değişebilir.

RLS Bypass Yetkisini Sınırlandırmak

BYPASSRLS çok geniş yetkidir ve normal admin tool için bile doğrudan verilmemelidir. Dedicated reporting database veya security definer function gibi daha dar yollar tercih edilebilir. Credential erişimi secret manager policy ile sınırlandırılmalıdır. Kullanım alert ve audit oluşturmalıdır. Düzenli permission review bu yetkinin gereksiz yayılmasını önler.

Multi-Tenant Sistemlerde Backup

Backup stratejisi kullanılan tenancy modeline göre ciddi biçimde değişir. Shared schema'da full database backup tüm tenant'ları birlikte içerirken database-per-tenant modelinde her tenant ayrı backup policy alabilir. Incremental backup ve point-in-time recovery veri kaybı hedeflerini iyileştirir. Backup encryption her model için zorunlu düşünülmelidir. En önemli nokta backup alınabiliyor olmasının tek tenant restore edilebildiği anlamına gelmediğini anlamaktır.

Full Database Backup

Full backup database'in tamamını belirli zamandaki haliyle saklar. Shared schema'da tüm tenant verisi aynı artefact içinde bulunur. Restore genellikle ayrı temporary database'e yapılır. Tek tenant recovery için gerekli satırlar daha sonra ayrıştırılır. Backup süresi ve storage maliyeti büyüme trendiyle izlenmelidir.

Incremental Backup

Incremental yöntem yalnızca değişen veri bloklarını veya logları saklayabilir. Backup süresi ve storage maliyetini azaltır. Recovery chain güvenilir biçimde test edilmelidir. Tenant-level restore yine ek extraction süreci gerektirebilir. Backup metadata encryption ve retention policy ile birlikte yönetilmelidir.

Point-in-Time Recovery

PITR belirli zaman noktasına database'i geri döndürmeyi sağlar. Yanlış delete veya migration hatasında değerlidir. Shared database'i production üzerinde doğrudan eski zamana döndürmek diğer tenant'ları da etkiler. Bu nedenle temporary restore database kullanılır. Hedef tenant satırları çıkarılıp production'a kontrollü geri aktarılır.

Shared Schema Backup

Shared schema backup operasyonel olarak basittir çünkü tek database backup alınır. Zorluk tenant-specific restore aşamasında ortaya çıkar. Tenant verisi birden fazla tabloda ve object storage'da dağılmış olabilir. Export dependency order ve foreign key ilişkileri yönetilmelidir. Düzenli tenant restore drill yapılmalıdır.

Schema-Per-Tenant Backup

Schema-level dump tenant verisini daha doğal biçimde ayırabilir. Yine de shared global table dependencies dikkate alınmalıdır. Full database backup disaster recovery için korunmaya devam edebilir. Tenant schema restore farklı environment'ta doğrulanmalıdır. Schema version application compatibility ile eşleşmelidir.

Database-Per-Tenant Backup

Tenant database'i bağımsız backup ve PITR policy alabilir. Enterprise SLA için güçlü avantajdır. Restore başka tenant'ları etkilemez. Backup job sayısı tenant sayısıyla büyür. Policy automation ve failure monitoring zorunludur.

Backup Encryption

Backup data production kadar hassastır. Encryption at rest ve secure key management uygulanmalıdır. Tenant-specific key gerekiyorsa restore workflow key availability'yi dikkate almalıdır. Offboarding sonrası backup retention ve key destruction policy birlikte tasarlanmalıdır. Backup access audit edilmelidir.

Per-Tenant Restore Problemi

Shared database'de tek tenant restore etmek en zor operasyonlardan biridir. Production database'i tamamen eski zamana döndürmek diğer tenant'ların yeni verisini kaybetmesine yol açar. Bu nedenle backup temporary environment'a restore edilir, ilgili tenant satırları ayrıştırılır ve production'a geri aktarılır. Foreign key ve conflict resolution dikkatle yönetilmelidir. Bu runbook production incident anında ilk kez denenmemeli, düzenli olarak test edilmelidir.

Tüm Database'i Restore Etmek

Backup ayrı temporary database'e restore edilir. Production doğrudan değiştirilmez. Restore point tenant data loss zamanına göre seçilir. Büyük database restore süresi RTO'yu etkiler. Infrastructure capacity bu emergency operation için önceden planlanmalıdır.

Tenant Verisini Ayıklamak

Temporary database içinde yalnızca hedef tenant satırları export edilir. Tüm tenant-scoped tablolar dependency graph üzerinden bulunmalıdır. Forgotten table data loss yaratabilir. Global tables genellikle export edilmez. Automation tenant ownership metadata'sından tablo listesini üretebilir.

Temporary Restore Database

Temporary environment production network'ünden güvenli biçimde ayrılmalıdır. Backup decrypted data içerdiği için access sıkı olmalıdır. Restore tamamlandığında gerekli validation yapılır. Tenant export alındıktan sonra temporary database güvenli biçimde silinir. Audit operation süresini kaydeder.

Tenant Rows Export

Export query tenant ID ile explicit scope edilmelidir. Composite relationships ve ordering dikkate alınabilir. Çok büyük tenant için chunked export gerekir. Export file encrypt edilmelidir. Row count ve checksum validation yapılmalıdır.

Conflict Resolution

Production'da restore point sonrasında yeni tenant data oluşmuş olabilir. Eski data'yı körlemesine overwrite etmek yeni kayıtları kaybettirebilir. Resource-level merge policy gerekir. Deleted row restore edilip edilmeyeceği business requirement'a bağlıdır. Support ve customer ile restore kapsamı açık biçimde belirlenmelidir.

Production'a Geri Aktarma

Import kontrollü transaction veya batch workflow ile yapılmalıdır. RLS ve tenant integrity constraint'leri aktif kalmalıdır. Conflict handling strategy uygulanır. Büyük import interactive traffic'i etkilememelidir. Import sonrası cache ve search index re-sync gerekebilir.

Restore Validation

Row count, business aggregate ve kritik sample resource'lar doğrulanmalıdır. Application smoke test tenant context altında çalıştırılır. File ve search data tutarlılığı kontrol edilir. Customer confirmation gerekebilir. Restore completion audit log'a kaydedilir.

Backup Var Demek Tenant Restore Edilebilir Demek Değildir

Birçok ekip backup job'un başarılı çalışmasını disaster recovery hazırlığı olarak görür, fakat asıl soru istenen tenant verisinin kabul edilebilir sürede geri getirilebilmesidir. Shared schema sistemlerde bu işlem data extraction ve conflict resolution gerektirir. Restore runbook düzenli test edilmezse incident anında beklenmeyen eksikler ortaya çıkar. RPO ve RTO tenant segmentine göre açık biçimde tanımlanmalıdır. Gerçek restore süresi ölçülmeli ve müşteri sözleşmesiyle uyumlu olup olmadığı doğrulanmalıdır.

Restore Runbook

Runbook backup location, restore environment, export ve import adımlarını açıkça tanımlar. Hangi ekiplerin hangi yetkiyle işlem yapacağı belirtilmelidir. Command ve script'ler version control altında tutulabilir. Manual adımlar azaltılmalıdır. Her drill sonrası runbook güncellenmelidir.

Tenant-Level Restore Testi

Test tenant için veri kaybı senaryosu simüle edilir. Backup temporary database'e restore edilir ve yalnızca tenant data geri alınır. Gerçek süre ölçülür. Search, files ve cache recovery de dahil edilmelidir. Test sonucu RTO hedefiyle karşılaştırılır.

RPO

Recovery Point Objective kabul edilebilir maksimum veri kaybı süresidir. Backup frequency veya continuous log shipping bu hedefi belirler. Enterprise tenant daha düşük RPO isteyebilir. Shared ve dedicated model farklı SLA sunabilir. RPO yalnızca backup schedule değil, restore edilebilir log zinciriyle doğrulanmalıdır.

RTO

Recovery Time Objective hizmet veya verinin ne kadar sürede geri getirileceğini ifade eder. Büyük shared database restore saatler sürebilir. Tenant-specific export ve validation ek zaman alır. Dedicated database daha kısa tenant RTO sağlayabilir. Gerçek drill süresi sözleşmedeki hedefle karşılaştırılmalıdır.

Restore Süresini Ölçmek

Tahmini süre yerine gerçek backup boyutu üzerinde test yapılmalıdır. Restore, extraction, import ve validation ayrı ayrı ölçülmelidir. Data büyüdükçe trend izlenmelidir. RTO aşılmaya başlamadan architecture iyileştirilmelidir. Büyük tenant promotion kararına restore süresi de girdi olabilir.

Düzenli Disaster Recovery Testleri

Yılda veya çeyrekte belirli aralıklarla restore drill yapılabilir. Random tenant seçmek gerçek coverage sağlar. Test yalnızca database değil tenant directory ve object storage'ı da kapsamalıdır. Findings backlog'a dönüştürülmelidir. DR readiness yaşayan bir süreç olmalıdır.

Tenant Offboarding Nasıl Yapılır?

Tenant offboarding subscription iptalinden verinin kalıcı silinmesine kadar uzanan kontrollü lifecycle sürecidir. Access hemen kapatılabilir fakat data retention sözleşme veya KVKK gereksinimine göre belirli süre devam edebilir. Customer export seçeneği sunulabilir. Retention window sonunda database, file storage, search index ve credential temizliği birlikte yapılmalıdır. Backup retention ve deletion audit ayrıca tanımlanmalıdır.

Subscription Kapatma

Billing sistemi tenant state'i cancelled veya offboarding durumuna geçirir. Yeni paid operation'lar engellenebilir. Data retention policy hemen deletion anlamına gelmeyebilir. Customer export süresi başlatılabilir. Control plane event ilgili servisleri bilgilendirir.

Access Revocation

User session ve API key erişimleri kapatılır. Token revocation veya tenant state check uygulanabilir. Background job'lar durdurulmalıdır. Support access ayrıca revoke edilir. Audit hangi credential'ların kapatıldığını gösterir.

Data Export

Müşteriye verisini alma imkanı sözleşme ve ürün politikasına göre sunulabilir. Export tenant-scoped olmalıdır. Dosyalar encrypted temporary storage'da tutulabilir. Signed download link kısa süre geçerli olmalıdır. Export tamamlandığında audit kaydı oluşturulur.

Retention Window

Data belirli süre recovery veya contract nedeniyle saklanabilir. Tenant application erişimi kapalı kalır. Retention bitiş tarihi control plane'de tutulmalıdır. Legal hold durumları ayrıca işaretlenebilir. Süre sonunda deletion workflow otomatik başlayabilir.

Data Deletion

Shared schema'da tüm tenant-scoped tablolar güvenli sırayla temizlenmelidir. Dedicated database modelinde database drop daha doğrudan olabilir. Object storage ve search data unutulmamalıdır. Large delete workload production performansını etkilememelidir. Deletion completion verification yapılmalıdır.

Backup Retention

Deleted tenant data mevcut backup'larda retention süresi boyunca kalabilir. Privacy policy bu durumu açıkça tanımlamalıdır. Backup içinden tek tenant'ı hemen silmek teknik olarak zor olabilir. Retention kısa ve gerekçeli olmalıdır. Restore sırasında deleted tenant'ın production'a yanlışlıkla geri gelmemesi için tombstone metadata kullanılabilir.

Tenant Credential Silme

Database user, API key ve storage credential revoke edilmelidir. Secret manager entries retention policy'ye göre silinir. Rotation job artık tenant'ı işlememelidir. Credential deletion failure security alert oluşturabilir. Tenant directory secret reference temizlenir.

Deletion Audit

Offboarding tamamlandığında hangi kaynakların ne zaman silindiği audit edilir. Database, storage, search ve credential ayrı adım olarak kaydedilebilir. Customer request ID veya legal basis saklanabilir. Audit hassas deleted data'yı içermemelidir. Compliance review için rapor üretilebilir.

Tenant Data Export

Tenant data export yalnızca birkaç CSV dosyası üretmekten daha kapsamlı bir izolasyon sürecidir. Export içinde başka tenant verisi bulunmadığı otomatik olarak doğrulanmalıdır. Büyük tenant export'ları background job olarak çalıştırılmalı ve progress takip edilmelidir. File storage object'leri ve ilişkili metadata ayrıca paketlenebilir. Secure download kısa ömürlü erişim linki ve güçlü authorization ile sunulmalıdır.

CSV

CSV kullanıcıların kolay açabildiği basit format sunar. Birden fazla entity ayrı dosyalara bölünebilir. Tenant ID internal field olarak kullanıcıya gösterilmeyebilir. Encoding ve delimiter standardize edilmelidir. Export row count source query ile doğrulanmalıdır.

JSON

JSON nested ve structured data için daha zengin format sunar. API representation'a yakın olabilir. Large dataset streaming ile yazılmalıdır. Sensitive internal metadata filtrelenmelidir. Schema version export manifest içinde belirtilebilir.

Database Dump

Enterprise tenant için schema veya dedicated database dump sunulabilir. Shared schema'da yalnızca tenant rows ayıklanması gerekir. Dump restore edilebilirliği test edilmelidir. Credential ve internal system table'lar dışarı verilmemelidir. File encryption ve secure transfer uygulanmalıdır.

File Storage

Tenant object storage dosyaları export paketine dahil edilebilir. Object key mapping manifest oluşturabilir. Signed URL yerine archive üretmek büyük export için daha kullanışlı olabilir. Missing file referansları validation'da görünür olmalıdır. Başka tenant prefix'i kesinlikle pakete girmemelidir.

Export İçinde Başka Tenant Verisi Olmadığını Test Etmek

Test fixture'larında Tenant A ve Tenant B benzersiz marker data kullanabilir. Tenant A export içinde Tenant B marker bulunmamalıdır. Database, file ve search kaynakları ayrı kontrol edilmelidir. Property-based test random tenant data ile coverage artırabilir. Export endpoint high-risk security test kategorisinde tutulmalıdır.

Large Export Job

Büyük export request-response süresinde tamamlanmamalıdır. Background worker chunk'lar halinde data okuyabilir. Progress ve retry state tutulur. Tenant resource quota heavy export sayısını sınırlandırabilir. Job tamamlandığında secure download notification gönderilebilir.

Secure Download

Export file encrypted temporary storage'da tutulmalıdır. Signed URL kısa TTL ile oluşturulur. Link oluşturulurken user'ın tenant permission'ı yeniden doğrulanmalıdır. One-time token veya additional authentication kullanılabilir. Retention sonunda file otomatik silinmelidir.

KVKK ve Veri Yaşam Döngüsü

Multi-tenant SaaS tasarımında kişisel verilerin nerede tutulduğunu, ne kadar süre saklandığını ve nasıl silineceğini baştan planlamak gerekir. Tenant modeli retention ve export gibi işlemleri customer bazında uygulamayı mümkün kılmalıdır. Backup içinde kalan kişisel veri için ayrı retention yaklaşımı gerekebilir. Audit yapılırken gereksiz kişisel data loglanmamalıdır. Teknik uygulamanın güncel hukuki ve sözleşmesel gereksinimlerle birlikte değerlendirilmesi önemlidir.

Veri Minimizasyonu

Uygulama yalnızca business amacı için gerekli veriyi toplamalıdır. Gereksiz tenant ve kullanıcı metadata'sı security riskini büyütür. Log ve analytics pipeline da minimizasyon kapsamındadır. Sensitive fields kullanım amacıyla eşleştirilmelidir. Schema review yeni kişisel alan eklenirken retention gereksinimini değerlendirebilir.

Saklama Süresi

Data retention tenant contract veya data category'ye göre değişebilir. Control plane tenant-specific policy saklayabilir. Background deletion job süresi dolan kayıtları temizleyebilir. Backup retention ayrı hesaplanmalıdır. Legal hold durumları normal deletion workflow'undan ayrılmalıdır.

Silme

Deletion database satırları kadar cache, search ve file storage'ı da kapsamalıdır. Soft delete kullanıcı deneyimi için kullanılıyorsa kalıcı deletion ayrıca tanımlanmalıdır. Tenant offboarding geniş çaplı delete workflow tetikler. Completion verification yapılmalıdır. Audit deleted payload yerine operation metadata saklamalıdır.

Export

Data portability için tenant veya user export mekanizması gerekebilir. Export yalnızca yetkili request sahibine sunulmalıdır. Tenant isolation automated test ile doğrulanmalıdır. Format anlaşılır ve yeterli olmalıdır. Export file retention kısa tutulmalıdır.

Audit

Access ve lifecycle operations audit edilmelidir. Audit log gereksiz sensitive data taşımamalıdır. Tenant ID, actor ve action temel metadata'dır. Support erişimleri özellikle kaydedilmelidir. Log retention ayrı güvenlik policy'sine tabi olabilir.

Tenant Bazlı Retention

Enterprise müşteri farklı retention süreleri talep edebilir. Tenant directory veya policy service bu değeri saklayabilir. Data deletion job tenant policy'yi okur. Shared schema'da farklı tenant retention query'leri dikkatli tasarlanmalıdır. Dedicated database tenant-specific archive stratejisini kolaylaştırabilir.

Backup'lardaki Kişisel Veriler

Production'dan silinen veri backup retention süresince kalabilir. Bu durum policy ve süreçlerde açıkça yönetilmelidir. Backup immutable olduğu için tek kaydı silmek zor olabilir. Retention süreleri gereksiz uzun tutulmamalıdır. Restore sonrası deleted data'nın yeniden aktif sisteme dönmesini engelleyen deletion ledger kullanılabilir.

Tenant Bazlı Data Residency

Data residency tenant verisinin hangi ülke veya region içinde tutulacağını belirleyen gereksinimdir. Tenant directory region bilgisini taşımalı ve provisioning doğru regional database cluster'a yapılmalıdır. Application routing aktif tenant'ın region'ını dikkate almalıdır. Cross-region analytics veya support erişimi veri politikalarıyla uyumlu tasarlanmalıdır. Region değiştirmek tenant migration kadar dikkatli data copy ve cutover süreci gerektirir.

Region

Region tenant data plane'in bulunduğu coğrafi altyapı alanını belirtir. Provisioning sırasında subscription veya compliance kuralına göre seçilebilir. Immutable olmak zorunda değildir fakat migration maliyetlidir. Backup da doğru region policy'ye uymalıdır. Tenant-facing contract region garantisini açıkça ifade etmelidir.

Country

Bazı gereksinimler geniş region yerine belirli ülke sınırı isteyebilir. Infrastructure sağlayıcının gerçek data location özellikleri doğrulanmalıdır. Application metadata country requirement ile actual cluster location'ı eşleştirmelidir. Cross-border backup veya analytics ayrıca değerlendirilmelidir. Hukuki yorum gerekli olduğunda uzman görüşü alınmalıdır.

Tenant Directory'de Region Bilgisi

Directory her tenant'ın active region'ını saklar. Routing layer buna göre database ve object storage endpoint seçer. Region migration sırasında source ve target state birlikte tutulabilir. Cache stale mapping'e karşı versioned route kullanabilir. Audit region değişikliğini kaydetmelidir.

Region Bazlı Database Cluster

Her region kendi database cluster setine sahip olabilir. Shard mapping region içinde yönetilir. Backup ve replica aynı residency sınırında tutulabilir. Operations tooling çok region'ı merkezi gözlemlemelidir. Schema version drift region'lar arasında oluşmamalıdır.

Tenant Routing

HTTP request global edge üzerinden tenant directory'ye göre doğru regional backend'e yönlendirilebilir. Routing latency cache ile azaltılabilir. User fiziksel olarak başka region'da olsa bile data policy correct region'ı belirler. Failover başka region'a geçecekse compliance etkisi değerlendirilmelidir. Route decision trace metadata'ya eklenebilir.

Cross-Region Analytics

Central analytics tüm tenant data'yı tek region'a taşımak residency policy'yi ihlal edebilir. Aggregate veya anonymized data kullanılabilir. Regional warehouse'lar sonuç seviyesinde birleştirilebilir. Tenant-specific restriction metadata pipeline tarafından korunmalıdır. BI access aynı policy'yi uygulamalıdır.

Tenant'ı Region'lar Arasında Taşımak

Region migration target database provisioning ile başlar. Historical data encrypted transfer ile kopyalanır. Incremental sync cutover'a kadar devam eder. DNS, object storage ve search mapping birlikte değişir. Source data retention ve deletion policy tamamlandıktan sonra migration kapanır.

Tenant Bazlı Encryption

Encryption at rest tüm multi-tenant sistemler için temel güvenlik önlemidir. Enterprise tenant'lar tenant-specific key veya BYOK isteyebilir. Key rotation ve access audit storage isolation kadar önemlidir. Encryption tenant isolation'ın yerine geçmez, çünkü yanlış authorization durumunda application yine decrypt edilmiş başka tenant verisini gösterebilir. Encryption ve database access control birbirini tamamlayan bağımsız katmanlardır.

Encryption at Rest

Database ve object storage fiziksel disk üzerindeki veriyi şifreleyebilir. Backup encryption da aynı politikanın parçasıdır. Key management altyapıdan ayrılmalıdır. Encryption performans overhead benchmark edilebilir. Access control yanlışsa at-rest encryption tek başına data leak'i önlemez.

Platform-Managed Key

Platform tüm tenant'lar için merkezi managed key kullanabilir. Operasyon basittir. Key rotation altyapı seviyesinde yapılabilir. Premium customer tenant-specific key talep edebilir. Global key leak blast radius'u threat model içinde değerlendirilmelidir.

Tenant-Specific Key

Her tenant'ın data encryption key'i ayrı tutulabilir. Key compromise etkisi tek tenant'a indirilebilir. Key sayısı büyüdükçe lifecycle automation önem kazanır. Storage layer envelope encryption kullanabilir. Tenant offboarding key destruction data erişimini kalıcı biçimde kesmeye yardımcı olabilir.

BYOK

Bring Your Own Key modelinde enterprise müşteri kendi key yönetim kontrolüne sahip olur. Application key reference tenant metadata'sında tutulabilir. Key unavailable olduğunda tenant data erişimi durabilir. Rotation ve revocation customer coordination gerektirir. Product SLA bu dependency'yi açıkça belirtmelidir.

Key Rotation

Encryption key periyodik veya incident sonrası değiştirilebilir. Envelope encryption data'yı tamamen yeniden yazmadan rotation kolaylığı sağlayabilir. Key version metadata tutulmalıdır. Old key ancak gerekli data re-encryption tamamlandıktan sonra kapatılmalıdır. Rotation progress monitoring yapılmalıdır.

Tenant Offboarding Sonrası Key Destruction

Tenant-specific key kullanılıyorsa offboarding sonunda key destruction ek deletion güvenliği sağlayabilir. Backup retention policy ile koordineli olmalıdır. Key erken silinirse yasal veya sözleşmesel restore ihtiyacı mümkün olmayabilir. Destruction approval gerekebilir. Audit key ID ve deletion tarihini kaydedebilir.

Encryption'ın Database Isolation Yerine Geçmemesi

Application database'den satırı okuyabiliyorsa çoğu durumda decrypted değerle çalışır. Bu nedenle yanlış tenant query encryption tarafından engellenmez. RLS, authorization ve tenant filter hâlâ gereklidir. Encryption disk veya backup compromise gibi farklı threat'lere karşı koruma sağlar. Katmanların sorumlulukları açıkça ayrılmalıdır.

Multi-Tenant Schema Migration Stratejileri

Multi-tenant sistemde schema migration mümkün olduğunca geriye uyumlu ve kademeli yapılmalıdır. Expand-and-contract yaklaşımı önce yeni alanı ekler, application dual compatibility kazanır, ardından eski alan daha sonra temizlenir. Schema-per-tenant ve database-per-tenant modellerinde migration batch ve canary yaklaşımı özellikle önemlidir. Tenant schema version merkezi olarak izlenmelidir. Retry ve rollback planı destructive migration başlamadan önce hazırlanmalıdır.

Expand-and-Contract

İlk aşamada yeni column veya table additive biçimde eklenir. Application hem eski hem yeni schema ile çalışabilir. Backfill tamamlanır ve read path yeni alana geçirilir. Observation sonrası eski column kaldırılır. Bu model zero-downtime migration riskini azaltır.

Backward-Compatible Migration

Yeni application eski schema ile kısa süre çalışabilmeli veya tam tersi desteklenmelidir. Rolling deployment sırasında farklı application version'ları aynı database'e erişebilir. Required column eklemek yerine nullable başlayabilir. Default value backfill kontrollü yapılır. Compatibility window migration bitince kapatılır.

Online Schema Changes

Büyük tablo üzerinde DDL uzun lock oluşturabilir. Database'in online migration özellikleri veya shadow table yaklaşımı değerlendirilebilir. Index creation concurrent yöntemle yapılabilir. Production traffic etkisi staging benzeri dataset'te test edilmelidir. Tenant batch migration workload'u ayrıca sınırlandırılmalıdır.

Schema Version

Her database veya schema current version metadata'sı tutmalıdır. Orchestrator target version ile karşılaştırır. Application minimum compatible version kontrolü yapabilir. Version drift dashboard operasyon ekibine görünürlük sağlar. Restore sonrası version yeniden doğrulanmalıdır.

Tenant Batch

Yüzlerce tenant aynı anda migrate edilmemelidir. Batch size database capacity ve risk seviyesine göre belirlenir. Internal ve small tenant canary olarak başlayabilir. Enterprise tenant'lar planlı window alabilir. Batch tamamlanma metric'i rollout kararını destekler.

Canary Migration

İlk tenant grubunda migration ve application behavior doğrulanır. Error ve performance regression izlenir. Başarısızlıkta rollout durur. Fix sonrası canary tekrar çalıştırılır. Bu yaklaşım widespread schema problem riskini önemli ölçüde azaltır.

Migration Retry

Temporary failure yeniden denenebilir. Migration step idempotent veya state-aware olmalıdır. Lock timeout ile data error ayrılmalıdır. Retry count sınırı bulunmalıdır. Sürekli başarısız tenant manual review'a taşınabilir.

Rollback

Rollback en kolay additive migration aşamasında uygulanır. Destructive column drop geri dönüşü zorlaştırır. Bu nedenle cleanup ayrı release'e bırakılabilir. Database-per-tenant modelinde tenant-specific restore gerekebilir. Rollback runbook test edilmelidir.

Zero-Downtime Tenant Migration

Zero-downtime migration amacı application trafiğini durdurmadan schema ve data yapısını değiştirmektir. Additive schema change ile başlanır, gerekli data backfill edilir ve application bir süre hem eski hem yeni modeli destekler. Daha sonra read ve write path yeni yapıya geçirilir. Eski column ancak tüm tenant ve application version'ları hazır olduğunda kaldırılır. Long-running backfill ve migration'ların database workload'unu etkilememesi için throttling uygulanmalıdır.

Additive Schema Change

Yeni column nullable veya default-safe biçimde eklenir. Eski application version etkilenmez. Index gerekiyorsa online veya concurrent yöntemle oluşturulabilir. Migration duration monitoring yapılmalıdır. Tenant-specific schema modelinde canary batch kullanılmalıdır.

Backfill

Existing rows yeni field veya table'a taşınır. Büyük dataset chunk'lar halinde işlenir. Job tenant ve primary key range ile partition edilebilir. Database load sınırlandırılır. Progress ve retry state tutulur.

Dual Compatibility

Application geçici süre eski ve yeni data representation ile çalışır. Write path iki alanı güncelleyebilir veya fallback read uygulanabilir. Bu dönem mümkün olduğunca kısa tutulmalıdır. Divergence metric oluşturulabilir. Feature flag rollout kontrolü sağlar.

Application Deployment

Yeni application release önce schema addition tamamlandıktan sonra deploy edilir. Rolling deployment boyunca old ve new instance'lar database ile uyumlu olmalıdır. Error rate izlenir. Migration feature gradual açılabilir. Rollback eski schema ile çalışmaya devam edebilmelidir.

Old Column Cleanup

Yeni model stabil olduktan sonra eski column usage telemetry ile doğrulanır. Application code artık eski alana erişmemelidir. Column drop ayrı maintenance release olarak yapılabilir. Backup ve rollback ihtiyacı değerlendirilir. Schema documentation güncellenir.

Long-Running Migration'ları Kontrol Etmek

Backfill saatler veya günler sürebilir. Batch size ve sleep interval database load'a göre dinamik ayarlanabilir. Tenant SLO etkisi izlenir. Job checkpoint restart sonrası devam etmeyi sağlar. Heavy tenant ayrı zaman diliminde işlenebilir.

Database-Per-Tenant Migration Orchestrator

Database-per-tenant yapıda application release tek database migration'dan yüzlerce migration'a dönüşür. Orchestrator tenant listesini, current schema version'ı ve target version'ı takip eder. Queue, concurrency limit ve retry mekanizması database load'unu kontrol altında tutar. Failure state tenant bazında izole edilir. Migration dashboard hangi tenant'ın hangi version'da olduğunu gerçek zamanlı gösterir.

Tenant Listesi

Orchestrator active tenant'ları directory'den alır. Suspended veya offboarding tenant policy'ye göre dahil edilebilir. Region ve tier batching kararını etkileyebilir. Liste snapshot olarak rollout ID ile saklanabilir. Yeni tenant provisioning current version ile doğrudan başlamalıdır.

Current Schema Version

Her tenant database mevcut version bilgisini taşır. Directory cache bu bilgiyi gösterebilir. Orchestrator actual database metadata ile doğrulama yapabilir. Drift bulunan tenant ayrı queue'ya alınır. Restore edilmiş eski database otomatik tespit edilebilir.

Target Version

Release target schema version belirler. Tenant migration yalnızca bir sonraki gerekli adımları çalıştırır. Multiple version skip destekleniyorsa migration path test edilmelidir. Application minimum compatible version metadata'sı tutulabilir. Target version release artefact ile immutable ilişkilendirilmelidir.

Migration Queue

Tenant ID ve target version job olarak queue'ya eklenir. Priority canary ve enterprise schedule'a göre belirlenebilir. Worker lease duplicate execution'ı engeller. Progress state persistent tutulur. Queue depth rollout tahmini sağlar.

Concurrency Limit

Aynı anda çok fazla database migrate etmek control plane ve cluster kaynaklarını tüketebilir. Global ve region-specific concurrency limit kullanılabilir. Adaptive throttling error ve latency artışında worker sayısını azaltabilir. Large tenant ayrı slot alabilir. Limit production traffic metric'leriyle birlikte ayarlanmalıdır.

Failure State

Migration başarısız olduğunda tenant migration_failed state'e alınabilir. Error code ve step kaydedilir. Application eski schema ile uyumluysa tenant service almaya devam edebilir. Değilse maintenance state gerekebilir. Support dashboard açık remediation action göstermelidir.

Retry

Retry temporary errors için otomatik uygulanabilir. Data validation veya incompatible schema hatası manual review gerektirir. Exponential backoff database'i zorlamayı önler. Retry counter ve last error görünür olmalıdır. Idempotency migration script'in temel beklentisidir.

Migration Dashboard

Dashboard total tenant, completed, pending ve failed sayılarını gösterir. Region ve tier filtreleri sunabilir. Schema version distribution görünür hale gelir. Failure reason trend aynı migration bug'ını erken gösterebilir. Rollout owner ve release ID kaydedilmelidir.

Tenant Provisioning Nasıl Otomatikleştirilir?

Tenant provisioning registration'dan application activation'a kadar tekrarlanabilir workflow olarak tasarlanmalıdır. Storage modeli ne olursa olsun resource creation, migration, roles, initial admin ve billing adımları state machine içinde izlenebilir. Manuel operasyonlar tenant sayısı arttıkça hata ve bekleme süresi oluşturur. Her step idempotent ve retryable olmalıdır. Activation yalnızca health verification tamamlandığında yapılmalıdır.

Tenant Registration

Kullanıcı veya sales flow tenant request oluşturur. Tenant metadata control plane'e yazılır. State provisioning olur. Public slug veya domain uniqueness doğrulanır. Billing plan isolation tier'i belirleyebilir.

Resource Provisioning

Storage modeline göre shared shard allocation, schema veya dedicated database oluşturulur. Region ve tier bilgisi placement kararını etkiler. Infrastructure job audit edilir. Resource tags cost attribution için eklenebilir. Failure cleanup workflow'u bulunmalıdır.

Database Setup

Database, schema, role ve permission hazırlanır. Runtime role least privilege olur. Secret manager credential saklar. Connection test edilir. Directory route pending olarak kaydedilir.

Schema Migration

Current schema version yeni tenant storage'a uygulanır. Baseline hızlandırıcı olabilir. Migration doğrulanır. Error activation'ı durdurur. Version metadata directory'ye yazılır.

Default Roles

Tenant admin ve standard member gibi başlangıç roller oluşturulur. Permission set product plan'a göre değişebilir. Seed işlemi idempotent olmalıdır. Role ID'ler stable şekilde yönetilmelidir. Custom enterprise role sonradan eklenebilir.

Initial Admin

Tenant'ı oluşturan kullanıcı initial admin membership alabilir. Invitation veya account verification tamamlanmalıdır. User birden fazla tenant'a sahipse membership ayrı kaydedilir. Authentication global user identity kullanabilir. Audit initial admin assignment'ı kaydeder.

Billing

Subscription record tenant lifecycle ile bağlanır. Trial, active veya paid state olabilir. Isolation tier billing entitlement'tan türetilebilir. Payment failure access policy'yi etkileyebilir. Billing event'leri idempotent işlenmelidir.

Health Verification

Database read-write, cache, storage ve critical API smoke testleri çalıştırılır. Tenant context isolation doğrulanabilir. Provisioned route doğru region ve database'e gitmelidir. Health başarısızsa tenant active edilmez. Error otomatik retry veya support review'a gider.

Activation

Tüm kontroller başarılı olduğunda tenant state active olur. Routing cache güncellenir. Welcome notification gönderilebilir. Monitoring tenant metric'lerini toplamaya başlar. Activation event downstream sistemler için yayınlanabilir.

Tenant Lifecycle State Machine

Tenant lifecycle state machine hangi durumda hangi işlemlerin yapılabileceğini merkezi olarak tanımlar. Provisioning, active, suspended, migration, offboarding, archived ve deleted gibi state'ler kullanılabilir. Application, billing ve data platform aynı state semantics'ini paylaşmalıdır. State transition authorization ve audit gerektirir. Bu yaklaşım tenant'ın yarım provision edilmiş veya silinmekte olduğu sırada yanlış işlemlere izin verilmesini engeller.

Provisioning

Tenant kaynakları hazırlanıyor durumundadır. Normal application erişimi kapalı tutulur. Provisioning progress dashboard'da görünür. Retry ve cleanup çalışabilir. Başarılı health check active state'e geçiş sağlar.

Active

Tenant normal business işlemlerini yapabilir. Billing ve access policy geçerlidir. Monitoring SLO'ları aktif olur. Migration gerekiyorsa controlled state transition yapılabilir. Offboarding request active state'ten başlatılabilir.

Suspended

Tenant ödeme veya güvenlik nedeniyle geçici olarak durdurulabilir. Data korunur fakat normal erişim engellenir. Background jobs policy'ye göre durdurulur. Admin restore veya billing action devam edebilir. Unsuspend audit edilmelidir.

Migration

Tenant storage veya schema değiştiriyor olabilir. Bazı write işlemleri geçici olarak sınırlandırılabilir. Source ve target location metadata birlikte tutulabilir. Progress monitoring yapılır. Success active state'e, failure rollback veya error state'e gider.

Offboarding

Subscription sona ermiş ve retention süreci başlamıştır. User access kapalıdır. Data export mümkün olabilir. Deletion deadline hesaplanır. Credential ve background job'lar kontrollü kapatılır.

Archived

Tenant operational olarak inactive fakat retention nedeniyle data tutuluyor olabilir. Normal application routing kapalıdır. Restore veya legal access özel workflow gerektirir. Storage düşük maliyetli archive tier'e taşınabilir. Archive duration policy ile sınırlandırılır.

Deleted

Tenant active data ve credentials kaldırılmıştır. Directory minimal tombstone record tutabilir. Aynı public slug'ın yeniden kullanımı policy'ye bağlıdır. Backup retention bitene kadar historical data bulunabilir. Deleted state'ten normal active'e doğrudan dönüş desteklenmemelidir.

Her State İçin İzin Verilen İşlemler

State machine allowed operation matrix içermelidir. Suspended tenant read yapabilir mi, offboarding export alabilir mi gibi sorular net olmalıdır. API middleware tenant state'e göre request kontrolü yapabilir. Background worker aynı policy'yi kullanmalıdır. State-specific behavior integration testlerle doğrulanmalıdır.

Multi-Tenant Analytics Nasıl Tasarlanır?

Analytics workload'u OLTP database üzerinde doğrudan çalıştırmak multi-tenant performansını bozabilir. Tenant dashboard için read replica veya pre-aggregation kullanılabilir. Platform cross-tenant analytics için data warehouse, ETL veya event streaming daha uygun olabilir. Analytics pipeline boyunca tenant ID kaybolmamalıdır. Customer-facing BI sonuçları her zaman tenant scope ve row-level access kurallarını uygulamalıdır.

Tenant Dashboard

Her tenant kendi metrics ve reports'unu görür. Query tenant ID ile scope edilmelidir. Heavy aggregation precomputed olabilir. Cache key tenant-aware olmalıdır. Dashboard data freshness kullanıcıya açıkça gösterilebilir.

Cross-Tenant Internal Analytics

Platform product ve finance ekipleri tüm tenant'lar üzerinden aggregate analiz yapabilir. Bu erişim customer API'den ayrı role ve warehouse üzerinde olmalıdır. Sensitive fields gerekmedikçe taşınmamalıdır. Small-group privacy riskleri dikkate alınmalıdır. Audit ve BI permission policy uygulanmalıdır.

OLTP Database'de Analytics Çalıştırmanın Riskleri

Large scan ve aggregation interactive request latency'sini artırabilir. Shared database noisy neighbor etkisi büyür. Query timeout ve read replica yardımcı olabilir. Ağır historical analytics warehouse'a taşınmalıdır. Production OLTP yalnızca operasyonel query'ler için optimize edilmelidir.

Read Replica

Read replica tenant dashboard veya export query'lerini primary'den ayırabilir. Replica lag freshness'i etkiler. Critical write-after-read akışları primary kullanabilir. Tenant ID scoping replica üzerinde de uygulanmalıdır. RLS configuration replication modeline göre doğrulanmalıdır.

Data Warehouse

Warehouse cross-tenant analytics için ayrı compute sağlar. Tenant ID fact ve dimension tablolarında korunmalıdır. Customer BI query'leri row-level policy ile scope edilebilir. ETL data quality ve deletion propagation süreçleri gerektirir. Data residency tenant policy'si warehouse placement'i etkiler.

ETL / ELT

Operational data düzenli olarak analytics platformuna taşınır. Pipeline her record'un tenant ID'sini korur. Schema evolution versioned olmalıdır. Deleted tenant data warehouse'da da lifecycle policy'ye tabi tutulmalıdır. Data quality checks cross-tenant ID mixing riskini yakalamalıdır.

Event Streaming

Business event'ler analytics pipeline'a near-real-time data sağlayabilir. Event envelope tenant ID taşır. Producer trusted context'ten değeri ekler. Consumer tenant field eksik event'i karantinaya alabilir. Replay aynı isolation kurallarını korumalıdır.

Tenant ID'yi Analytics Pipeline'da Korumak

Tenant ID source'dan warehouse'a kadar lineage'ın parçası olmalıdır. Transform sırasında düşürülmesi customer data mixing riskini artırır. Aggregate table'larda tenant dimension gerektiğinde tutulmalıdır. Platform-wide aggregate özel erişim katmanına ayrılabilir. Data testleri tenant key null veya invalid olduğunda fail etmelidir.

Cross-Tenant Analytics Güvenliği

Platform analytics doğası gereği birden fazla tenant verisini işleyebilir, bu nedenle normal customer analytics'ten ayrı güvenlik sınırı gerektirir. BI tool, warehouse row-level access ve sensitive field masking birlikte kullanılmalıdır. Aggregate sonuçlar bile küçük tenant gruplarında kişisel veya ticari bilgiyi dolaylı biçimde ortaya çıkarabilir. Tenant filter customer-facing dashboard'da otomatik uygulanmalıdır. Platform analytics erişimi sınırlı role, approval ve audit ile yönetilmelidir.

Platform Analytics

Internal product veya finance analysis tüm tenant dataset'ine ihtiyaç duyabilir. Access yalnızca authorized BI role'e verilmelidir. Raw sensitive data gerekmedikçe maskelenmelidir. Query logs audit edilebilir. Export capability ayrıca sınırlandırılmalıdır.

Customer Analytics

Müşteri kendi tenant verisini görmelidir. Dashboard filter client tarafından kaldırılabilir biçimde olmamalıdır. Backend trusted tenant context'i query policy'ye aktarır. Shared BI dataset row-level security kullanabilir. Cross-tenant testler customer role ile düzenli çalıştırılmalıdır.

Tenant Filter

Tenant filter BI query'nin zorunlu koşuludur. Dashboard URL parametresine güvenilmemelidir. User identity ve membership ile derived tenant ID kullanılmalıdır. Warehouse row policy ek defense sağlar. Cache results tenant ID ile ayrılmalıdır.

BI Tool Security

BI tool user role ve dataset permission'ları açıkça yönetilmelidir. Service account tüm tenant data'ya sahip olup UI filter'a güvenmemelidir. Embedded analytics signed tenant context kullanabilir. Export ve drill-down ayrı permission gerektirebilir. Tool configuration version control veya automated audit ile izlenmelidir.

Row-Level Access

Warehouse veya BI layer satır seviyesinde tenant access uygulayabilir. Policy application filter'ı tamamlar. Admin analytics role ayrı tutulur. Row-level policy testleri Tenant A ve Tenant B fixtures ile yapılmalıdır. Policy change security review gerektirir.

Aggregate Data

Cross-tenant aggregate çoğu zaman raw data'dan daha düşük risk taşır. Yine de küçük müşteri sayısı veya segment data'sı tek tenant davranışını ortaya çıkarabilir. Minimum cohort size kullanılabilir. Sensitive metric'ler daha yüksek threshold isteyebilir. Customer-facing benchmark feature'larında privacy tasarımı ayrıca yapılmalıdır.

Small-Group Privacy Riskleri

İki veya üç tenant'tan oluşan aggregate değerler tek müşterinin bilgisini tahmin etmeyi kolaylaştırabilir. Segmentation filtreleri bu riski artırır. Minimum group threshold ve suppression uygulanabilir. Export permission sınırlanabilir. Analytics product tasarımı security ve privacy review'dan geçmelidir.

Multi-Tenant Database Monitoring

Multi-tenant monitoring global database CPU grafiğinden daha fazla ayrıntı gerektirir. Query latency, database size, row count, connection, error ve lock wait tenant boyutuyla ilişkilendirilmelidir. Tenant SLO'ları noisy neighbor etkisini görünür hale getirir. Schema version ve migration state operasyonel health'in parçasıdır. Büyük tenant'ın büyüme trendi future shard veya dedicated database ihtiyacını önceden göstermelidir.

Query Latency Per Tenant

p50, p95 ve p99 latency tenant bazında ölçülebilir. High cardinality metric cost dikkatle yönetilmelidir. Büyük tenant slow query fingerprint'leri belirlenebilir. SLO breach alert oluşturabilir. Migration öncesi ve sonrası karşılaştırma yapılabilir.

Database Size Per Tenant

Shared schema'da exact size hesaplamak zor olabilir fakat row count ve estimated bytes kullanılabilir. Dedicated database modelinde boyut doğrudan ölçülür. Growth trend cost ve capacity planning sağlar. Storage quota product tier ile ilişkilendirilebilir. Büyük tenant promotion threshold belirlenebilir.

Row Count Per Tenant

Kritik tabloların tenant bazlı row count'u data distribution'ı gösterir. Exact count pahalıysa sampled veya aggregated telemetry kullanılabilir. Sudden growth application bug veya import event'i olabilir. Index selectivity bu dağılımdan etkilenir. Migration tahmini tenant row count üzerinden yapılabilir.

Connection Count

Active ve waiting connection sayısı database saturation sinyali verir. Database-per-tenant pool modelinde tenant attribution önemlidir. Idle pool fazla ise eviction policy ayarlanabilir. Connection wait SLO'yu etkileyebilir. Proxy ve application pool metric'leri birlikte izlenmelidir.

Error Rate

Database timeout, deadlock ve constraint error oranları tenant bazında incelenebilir. Tek tenant'taki data problem global metric'te kaybolabilir. Migration sonrası error spike schema issue gösterebilir. Error code ve query fingerprint birlikte tutulmalıdır. Sensitive SQL parameter loglanmamalıdır.

Lock Wait

Long transaction ve migration lock contention yaratabilir. Wait event tenant veya query ile ilişkilendirildiğinde noisy neighbor bulunabilir. Alert threshold interactive request latency'sine göre belirlenir. Background job concurrency azaltılabilir. Schema DDL canary rollout kullanabilir.

CPU ve I/O

Shared database'de tenant-specific CPU attribution doğrudan zor olabilir. Query fingerprint, request tagging ve workload telemetry kullanılır. Dedicated database bu ölçümü kolaylaştırır. Hot shard tespitinde CPU ve I/O birlikte değerlendirilir. Cost attribution için de aynı data kullanılabilir.

Migration Version

Schema-per-tenant ve database-per-tenant sistemlerde version distribution kritik metriktir. Eski version'da kalan tenant application compatibility riskidir. Dashboard target version progress gösterir. Failed migration alert üretir. Restore edilen database'in yanlış version'a dönmesi otomatik tespit edilebilir.

Tenant SLO

Availability ve latency hedefi tenant tier'e göre farklı olabilir. Enterprise SLA daha sıkı olabilir. Noisy neighbor analizi bir tenant workload'unun diğer SLO'ları etkileyip etkilemediğini gösterir. SLO breach automatic promotion veya capacity action tetikleyebilir. Product ve infrastructure ekipleri aynı metrikleri kullanmalıdır.

Tenant Bazında Cost Attribution

Tenant bazında maliyet ölçümü hangi müşterinin storage, compute, network ve support kaynaklarını ne kadar tükettiğini anlamayı sağlar. Bu veri fiyatlandırma ve isolation tier kararlarında değerlidir. Shared infrastructure'da tam maliyet hesaplamak zor olabilir fakat request, storage ve workload metric'lerinden tahmin üretilebilir. Enterprise dedicated database maliyeti doğrudan ayrıştırılabilir. Gross margin görünürlüğü teknik mimari kararların ticari sürdürülebilirliğini güçlendirir.

Storage Cost

Tenant database rows, object storage ve search index boyutu ölçülebilir. Backup duplication ayrıca maliyet yaratır. Shared storage için proportional estimate kullanılabilir. Growth trend pricing veya archive policy'yi etkiler. Large tenant promotion kararı storage maliyetiyle desteklenebilir.

Query Cost

Database CPU time veya scanned rows query maliyet göstergesi olabilir. Ağır analytics tenant başına farklılık yaratır. Request sayısı tek başına yeterli değildir. Query class ve execution time kullanılabilir. High-cost feature premium tier'e alınabilir.

Compute

Application worker ve database compute tenant workload'a göre tahmin edilebilir. Request duration ve background job CPU data sağlar. Dedicated tenant compute doğrudan ölçülebilir. Shared pool'da attribution model yaklaşık olabilir. Trend gross margin planlamasına yardımcı olur.

Backup

Backup storage ve restore infrastructure maliyet yaratır. Database-per-tenant frequent backup premium SLA ile ilişkilendirilebilir. Shared database maliyeti tenant boyutuna göre dağıtılabilir. Long retention enterprise feature olabilir. Backup egress ve DR test maliyeti de hesaba katılmalıdır.

Network

API response, export ve cross-region replication network maliyeti oluşturur. Büyük tenant file download yükü yüksek olabilir. Region migration ciddi transfer maliyeti yaratabilir. Tenant-level egress metric faydalıdır. Pricing quota ile ilişkilendirilebilir.

Support Cost

Technical cost yalnızca infrastructure değildir. Bazı tenant'lar yoğun support ve manual migration gerektirebilir. Ticket ve support hour attribution gross margin'i daha doğru gösterir. Enterprise revenue yüksek olsa bile support yükü ayrıca ölçülmelidir. Automation support maliyetini azaltabilir.

Tenant Gross Margin

Tenant revenue ile estimated direct cost karşılaştırılır. Negative margin large tenant architecture problemine işaret edebilir. Dedicated isolation pricing yeterli değilse ürün paketi yeniden değerlendirilebilir. Cost trend contract renewal kararına girdi olur. Engineering optimizations financial impact ile ölçülebilir.

Enterprise Isolation Fiyatlandırması

Dedicated database, region veya key gerçek altyapı ve operasyon maliyeti taşır. Bu özellikler ücretsiz varsayılan haline getirilmemelidir. Enterprise plan izolasyonun sağladığı compliance ve SLO değerini fiyatlandırabilir. Provisioning ve support maliyeti modele dahil edilmelidir. Teknik ekip product pricing için ölçülebilir cost data sağlayabilir.

Multi-Tenant Database Nasıl Test Edilir?

Multi-tenant sistem testleri yalnızca business feature'ların doğru çalışmasını değil, tenant isolation invariant'ını da doğrulamalıdır. Tenant A ve Tenant B için benzer ID değerleri ve farklı marker data oluşturmak faydalıdır. Read, insert, update ve delete işlemlerinde başka tenant'a erişim denenmelidir. Cache, export ve background job gibi database dışı yollar da aynı test kapsamına alınmalıdır. Bu testler CI pipeline'da sürekli çalıştığında regresyon riski ciddi biçimde azalır.

Tenant A ve Tenant B Fixture'ları

İki tenant aynı resource ID veya slug değerlerine sahip olabilir. Bu düzen cross-tenant collision testini güçlendirir. Her tenant'ın benzersiz marker text'i bulunabilir. Test user'lar yalnızca kendi tenant'ına üye yapılır. Admin fixture ayrı tutulmalıdır.

Read Isolation

Tenant A session başka tenant resource ID ile GET yapar. Sonuç data döndürmemelidir. List endpoint Tenant B marker'ı içermemelidir. Search ve report dahil edilmelidir. RLS ve application filter path ayrı ayrı test edilebilir.

Insert Isolation

Tenant A request body içine Tenant B ID göndermeyi dener. Server trusted tenant context ile ownership set etmelidir. RLS veya constraint yanlış tenant insert'i reddetmelidir. Bulk insert ayrıca denenmelidir. Database'de oluşan satırın doğru tenant ID taşıdığı doğrulanır.

Update Isolation

Tenant A Tenant B resource ID'sini update etmeyi dener. Zero row affected veya authorization error beklenir. Ownership field değiştirilememelidir. Bulk update tenant scope'u korumalıdır. Audit başarısız denemeyi güvenlik gereksinimine göre loglayabilir.

Delete Isolation

Cross-tenant delete hiçbir satırı silmemelidir. Cascade behavior ayrıca test edilmelidir. Bulk delete endpoint yüksek risklidir. RLS DELETE policy doğrulanmalıdır. Tenant B fixture operation sonrası intact kalmalıdır.

Export Isolation

Tenant A export paketi yalnızca kendi satır ve dosyalarını içermelidir. Background export worker tenant context'i korumalıdır. Search veya analytics data source export'a giriyorsa ayrıca scope edilmelidir. Marker scanning automated yapılabilir. Large export test random fixture kullanabilir.

Cache Isolation

Aynı resource ID iki tenant için farklı response üretir. Tenant A cache fill sonrası Tenant B request yapılır. B yalnızca kendi data'sını görmelidir. Cache key tenant ID içermelidir. Eviction başka tenant entry'lerini silmemelidir.

Background Job Isolation

Tenant A ve B job'ları aynı worker pool'da paralel çalıştırılır. Database ve cache context karışmamalıdır. Retry sonrası tenant ID korunmalıdır. DLQ replay doğru tenant'ta çalışmalıdır. Worker global state testlerle kontrol edilir.

Cross-Tenant Data Leak Testleri

Cross-tenant leak testleri multi-tenant sistemin en kritik security test grubudur. Eksik tenant filter, yanlış ID, IDOR, bulk API, search, export ve file download gibi farklı saldırı yüzeyleri ayrı ayrı denenmelidir. Yalnızca UI üzerinden test yapmak yeterli değildir, HTTP request'ler manuel olarak değiştirilmelidir. Aynı resource ID'nin farklı tenant'larda bulunması collision senaryolarını güçlendirir. Testler her release'te otomatik çalışmalı ve failure blocking security issue kabul edilmelidir.

Eksik tenant_id Filter Testi

Repository veya test endpoint bilinçli olarak tenant filter olmadan query çalıştırabilir. RLS aktifse başka tenant data dönmemelidir. RLS yoksa test güvenlik riskini açık biçimde gösterir. Bu scenario defense in depth'in gerçekten çalıştığını doğrular. Production code'a unsafe endpoint dahil edilmemelidir.

Yanlış Tenant ID

Client header veya path içinde başka tenant ID gönderir. Membership check request'i reddetmelidir. Resource ID doğru olsa bile access sağlanmamalıdır. Audit gerekli görülürse suspicious attempt olarak kaydedilebilir. Error message başka tenant'ın varlığını gereksiz doğrulamamalıdır.

IDOR Testi

Insecure Direct Object Reference testi kullanıcı resource ID değerini değiştirerek başka kayda erişmeye çalışır. UUID kullanmak bu testi gereksiz kılmaz. Server tenant scope ve permission kontrol etmelidir. Nested resources ayrıca test edilmelidir. File ve export endpoint'leri de IDOR kapsamındadır.

Farklı Tenant'a Ait Resource ID

Tenant A session Tenant B'nin gerçek resource ID'sini kullanır. GET, update ve delete işlemleri reddedilmelidir. Parent-child endpoint'lerde parent ve child tenant eşleşmesi kontrol edilir. Composite foreign key write riskini azaltır. Test fixture gerçek ID ile çalıştığı için güvenlik garantisini daha güçlü doğrular.

Bulk API

Bulk endpoint array içindeki her item için tenant scope kontrol etmelidir. Tek doğru item nedeniyle tüm payload trusted kabul edilmemelidir. Tenant B resource ID'si araya eklenerek test yapılmalıdır. Partial failure behavior açık olmalıdır. Database bulk SQL RLS ile korunmalıdır.

Search

Search query Tenant B'ye özgü marker arar. Tenant A hiçbir sonuç görmemelidir. Suggestion ve aggregation API'leri de test edilmelidir. Search cache tenant-aware olmalıdır. Shared index filter removal senaryosu security suite'e dahil edilebilir.

Export

Export job uzun ve async olduğu için context kaybı riski taşır. Tenant A export içinde B marker bulunmamalıdır. Object storage ve search data dahil edilmelidir. Download authorization ayrıca test edilmelidir. Expired link tekrar kullanılamamalıdır.

Report

Report query çoğu zaman aggregate ve join kullandığı için tenant filter unutulma riski yüksektir. Tenant B metric'i Tenant A dashboard'unda görünmemelidir. Precomputed table'lar da tenant ID taşımalıdır. BI cache tenant scope ile keylenmelidir. Scheduled report email doğru tenant recipient'larına gitmelidir.

File Download

Tenant A başka tenant'a ait file ID veya object key ile download denemelidir. API authorization reddetmelidir. Signed URL yalnızca doğru resource için oluşturulmalıdır. CDN private cache behavior test edilmelidir. Guessable path hiçbir erişim avantajı sağlamamalıdır.

RLS Policy'leri Nasıl Test Edilir?

RLS testleri application query filter'ından bağımsız olarak database policy'nin gerçekten tenant boundary uyguladığını kanıtlamalıdır. Tenant A ve Tenant B için ayrı session context oluşturulur. SELECT, INSERT, UPDATE ve DELETE işlemleri gerçek runtime role ile denenir. Table owner ve elevated role davranışı ayrıca incelenir. Tenant context bulunmadığında default-deny sonucu doğrulanmalıdır.

Tenant A Session

Transaction içinde tenant A context set edilir. Application runtime role kullanılır. Tenant A satırları görünmelidir. Tenant B satırları aynı query'de görünmemelidir. Context reset transaction sonunda doğrulanmalıdır.

Tenant B Session

Aynı physical pool connection mümkünse Tenant B için yeniden kullanılır. Önceki tenant state'i kalmamalıdır. Yalnızca B rows görünmelidir. Cross-tenant write reddedilmelidir. Bu test pooling leak riskini de kapsar.

SELECT

Table scan veya filter-free query çalıştırılır. Policy yalnızca active tenant rows döndürmelidir. Join edilen tüm RLS tabloları ayrıca test edilmelidir. Aggregate count başka tenant satırlarını içermemelidir. Explain plan performance açısından incelenebilir.

INSERT

Active tenant'tan farklı tenant_id ile insert denenir. WITH CHECK policy reddetmelidir. Doğru tenant insert başarılı olmalıdır. Application-supplied tenant ID yerine server context kullanılır. Bulk insert senaryosu da test edilmelidir.

UPDATE

Tenant A session B row update etmeyi dener. Satır etkilenmemelidir. Tenant A row'un tenant ID'sini B'ye değiştirme denemesi reddedilmelidir. Normal business field update başarılı olmalıdır. Policy error predictable olmalıdır.

DELETE

B row delete tenant A session altında başarısız olmalıdır. Tenant A own row delete policy'ye göre başarılı olabilir. Cascade child rows tenant integrity'yi korumalıdır. Bulk delete test edilmelidir. Delete audit application seviyesinde doğrulanabilir.

Table Owner Testi

Table owner ile aynı query çalıştırılarak RLS bypass davranışı gözlemlenir. Bu test neden application runtime role ayrımının önemli olduğunu gösterir. Production credential owner olmamalıdır. FORCE RLS kullanılıyorsa behavior ayrıca doğrulanır. CI misconfiguration test'i runtime connection owner ise fail edebilir.

Runtime Role Testi

Test application'ın production'da kullandığı gerçek permission set'i ile çalışmalıdır. Migration superuser ile yapılan test yeterli değildir. Runtime role RLS policy'ye tabi olmalıdır. DDL ve bypass permission'a sahip olmamalıdır. Permission regression release gate olabilir.

Default-Deny Testi

Tenant context set edilmeden query yapılır. Güvenli davranış access'in reddedilmesi veya zero rows dönmesidir. Tüm tenant rows görünmemelidir. New table policy unutulduğunda test fail etmelidir. Default-deny guardrail schema evolution riskini azaltır.

Property-Based Tenant Isolation Testing

Property-based testing sabit birkaç örnek yerine çok sayıda rastgele tenant ve resource kombinasyonu üreterek isolation invariant'ını test eder. Temel invariant, hiçbir tenant'ın başka tenant resource'una erişememesidir. Random ID collision, membership ve operation kombinasyonları edge case yakalamayı kolaylaştırır. Test cross-tenant sonuç bulduğunda otomatik fail eder ve tekrar üretilebilir seed saklar. Bu yaklaşım klasik integration testlerin tamamlayıcısı olarak CI pipeline'da güçlü güvence sağlar.

Rastgele Tenant'lar Üretmek

Test framework random tenant ID ve membership setleri oluşturabilir. En az iki tenant garanti edilmelidir. Tenant state active veya suspended gibi farklı değerler alabilir. Generated data seed kaydedilmelidir. Failure aynı seed ile tekrar çalıştırılabilir.

Rastgele Resource'lar

Her tenant için random project, invoice veya file oluşturulur. Bazı entity ID değerleri bilinçli collision yapabilir. Parent-child ilişkiler random üretilir. Global entity'ler ayrı tutulur. Test database cleanup deterministik yapılmalıdır.

Farklı Tenant ID Kombinasyonları

Actor tenant ile resource tenant farklı kombinasyonlarda eşleştirilir. Same-tenant access başarılı, cross-tenant access başarısız olmalıdır. Request body yanlış tenant ID içerebilir. API, repository ve direct database layer ayrı test edilebilir. Bu matrix manual case yazma ihtiyacını azaltır.

Isolation Invariant

Invariant “actor yalnızca authorized tenant resource'larını görebilir veya değiştirebilir” şeklinde tanımlanır. Read, write ve delete operasyonları kapsanır. Cache ve background job için benzer invariant yazılabilir. Test framework tüm generated cases üzerinde bu kuralı doğrular. Tek ihlal blocking failure olur.

Cross-Tenant Sonuç Bulunduğunda Testi Fail Etmek

Result set içinde başka tenant ID bulunduğunda test hemen başarısız olmalıdır. Sensitive payload loglanmadan resource metadata gösterilebilir. Seed kaydedilir. Root cause repository, RLS veya cache olabilir. Fix sonrası aynı seed regression case olarak tutulabilir.

CI Pipeline'a Eklemek

Property-based test hızlı subset her pull request'te çalışabilir. Daha geniş iteration nightly pipeline'a bırakılabilir. Database migration değişikliklerinde iteration sayısı artırılabilir. Failure security severity ile ele alınmalıdır. Test coverage zaman içinde yeni entity ve data path'leri kapsayacak şekilde büyütülmelidir.

Noisy Neighbor Testleri

Noisy neighbor testleri tek tenant'a ağır workload uygulanırken diğer tenant'ların latency ve availability hedeflerinin korunup korunmadığını ölçer. Büyük tenant dataset'i, heavy query, connection saturation ve background job flood ayrı senaryolar olarak çalıştırılabilir. Sadece yük üreten tenant değil, komşu tenant p95 ve p99 latency değerleri izlenmelidir. Resource quota ve rate limit mekanizmaları test sırasında doğrulanır. Sonuçlar tenant SLO ve isolation tier kararlarına doğrudan girdi sağlar.

Büyük Tenant Simülasyonu

Test environment'da diğer tenant'lardan çok daha büyük dataset oluşturulur. Production en büyük tenant büyüklüğüne yakın değer kullanılmalıdır. Common query'ler benchmark edilir. Index ve query plan farkları izlenir. Small tenant latency ile karşılaştırma yapılır.

Heavy Query

Large aggregate veya complex join bilinçli olarak çalıştırılır. CPU ve I/O etkisi ölçülür. Query timeout mekanizması doğrulanır. Diğer tenant request'lerinin latency artışı kaydedilir. Gerekirse report async pipeline'a taşınır.

Connection Saturation

Tek tenant çok sayıda parallel request üretir. Pool wait time ve rejection behavior izlenir. Tenant rate limit diğer müşterilere connection bırakmalıdır. Dedicated pool veya queue ihtiyacı değerlendirilir. Global outage oluşmamalıdır.

Lock Contention

Long transaction veya update workload lock wait oluşturur. Diğer tenant query'leri ne kadar etkileniyor ölçülür. Composite indexes ve transaction design değerlendirilir. Deadlock behavior test edilir. Timeout ve retry storm gözlemlenir.

Background Job Flood

Bir tenant için binlerce job queue'ya eklenir. Scheduler fairness diğer tenant job'larının ilerlemesini sağlamalıdır. Tenant concurrency quota uygulanmalıdır. DLQ veya retry flood ayrıca test edilir. Queue wait time tenant bazında ölçülür.

Diğer Tenant'ların P95/P99 Latency'sini İzlemek

Global average latency noisy neighbor etkisini gizleyebilir. Baseline small tenant p95 ve p99 değerleri test öncesinde kaydedilir. Heavy tenant workload sırasında değişim ölçülür. SLO threshold aşılırsa isolation control yetersizdir. Dedicated routing veya rate limit ayarlanabilir.

Tenant SLO'larını Doğrulamak

Test sonucu her tenant tier için tanımlı SLO ile karşılaştırılır. Enterprise tenant başka standard tenant workload'undan ne kadar etkileniyor görülebilir. Resource policy ürün sözünü desteklemelidir. Failed scenario backlog'a alınır. Performance regression testleri release pipeline'a eklenebilir.

Multi-Tenant Database Disaster Recovery

Disaster recovery yalnızca database backup restore etmekten ibaret değildir. Zone veya region failure durumunda tenant directory, database, object storage ve routing birlikte değerlendirilmelidir. Shared shard failure belirli tenant grubunu etkileyebilir, dedicated tenant failover farklı runbook gerektirebilir. Replica promotion ve failback süreçleri test edilmelidir. Tenant route mapping recovery sırasında yanlış database'e yönlenmemelidir.

Database Failure

Primary database instance failure replica promotion veya managed failover ile karşılanabilir. Application connection retry policy kontrollü olmalıdır. Tenant routing endpoint değişikliğini görebilmelidir. In-flight transaction kaybı değerlendirilir. Recovery sonrası data consistency kontrol edilir.

Zone Failure

Multi-zone replica mimarisi zone outage etkisini azaltır. Database kadar application ve cache layer da failover yapmalıdır. Tenant directory yüksek availability sağlamalıdır. DNS veya proxy failover süresi ölçülmelidir. DR test gerçek zone isolation senaryosuna yakın yapılmalıdır.

Region Failure

Region-level disaster daha geniş data residency ve replication kararı gerektirir. Cross-region replica kullanılıyorsa compliance izin vermelidir. RPO network replication mode'a bağlıdır. Tenant routing alternate region'a çevrilebilir. Failback source region döndüğünde ayrı migration gibi yönetilmelidir.

Backup Restore

Replica failure dışında logical corruption durumunda backup gerekebilir. Full database veya tenant-specific restore runbook kullanılmalıdır. Backup integrity periyodik doğrulanmalıdır. Restore environment security kontrollü olmalıdır. RTO gerçek testlerle ölçülmelidir.

Replica Promotion

Replica yeni primary olduğunda connection endpoint güncellenir. Write readiness doğrulanır. Replication lag nedeniyle olası data loss RPO içinde kalmalıdır. Application idempotency duplicate operation riskini azaltır. Promotion audit ve incident timeline'a kaydedilir.

Tenant Directory Recovery

Directory kaybı doğru storage routing'i engelleyebilir. Bu nedenle backup ve replication ayrı önceliğe sahiptir. Data plane cached routes kısa süre çalışmaya devam edebilir. Directory restore sonrası mapping integrity doğrulanmalıdır. Stale migration state'leri reconciliation job ile düzeltilmelidir.

Dedicated Tenant Failover

Enterprise tenant ayrı database kullandığı için failover tenant-specific olabilir. SLA daha hızlı recovery isteyebilir. Dedicated replica veya standby tutulabilir. Customer communication planı bulunmalıdır. Failover başka tenant'ları etkilemeden uygulanabilir.

Failback

Emergency target'tan normal primary region veya cluster'a geri dönüş controlled migration'dır. Data delta senkronize edilir. Routing tekrar güncellenir. Rollback planı bulunmalıdır. Failback sonrası monitoring ve consistency validation yapılır.

Multi-Tenant Mimari İçin SQL mi NoSQL mi?

SQL veya NoSQL seçimi tenancy kavramından önce veri modeli, consistency ve query gereksinimine dayanmalıdır. PostgreSQL gibi relational sistemler constraint, transaction ve RLS özellikleriyle multi-tenant SaaS için güçlü başlangıç sunar. NoSQL sistemler yüksek ölçek veya belirli access pattern'lerinde avantaj sağlayabilir. Her iki yaklaşımda tenant key ve authorization sınırı açık biçimde tasarlanmalıdır. Teknoloji seçimi cross-tenant isolation test, backup ve migration ihtiyacını ortadan kaldırmaz.

PostgreSQL

PostgreSQL RLS, transaction, indexing ve schema özellikleriyle çok yönlü bir seçenektir. Shared schema'dan database-per-tenant modele kadar farklı tasarımlar desteklenebilir. JSONB esnek tenant metadata için yardımcı olabilir. Logical replication migration ve CDC senaryolarında kullanılabilir. Operational ekosistem geniştir.

MySQL

MySQL relational constraint ve transaction özellikleriyle multi-tenant SaaS için kullanılabilir. Tenant isolation çoğunlukla application scoping ve schema/database modeline dayanır. Index ve query plan tenant dağılımına göre test edilmelidir. Database-per-tenant provisioning automation uygulanabilir. Seçim ekip deneyimi ve mevcut altyapıyla birlikte değerlendirilmelidir.

SQL Server

SQL Server enterprise uygulamalarda güçlü relational özellikler sunar. Row-level security ve schema seçenekleri multi-tenancy için kullanılabilir. Operational licensing ve infrastructure modeli maliyet hesabına dahil edilmelidir. Tenant-level monitoring ve backup özellikleri değerlendirilmelidir. Application ORM ile integration iyi planlanmalıdır.

MongoDB

MongoDB document-oriented data modeli tenant field üzerinden shared collection tasarımını destekleyebilir. Database veya collection-per-tenant seçenekleri de bulunabilir. Tenant filter her query'de zorunlu tutulmalıdır. Index prefix tenant ID ile tasarlanabilir. Transaction ve relation ihtiyacı ürün domain'ine göre değerlendirilmelidir.

DynamoDB

DynamoDB partition key tasarımı multi-tenant erişim pattern'inin merkezindedir. Tenant ID partition key'in parçası olabilir. Hot partition noisy neighbor benzeri risk yaratabilir. IAM ve application authorization birlikte kullanılmalıdır. Data export, restore ve tenant migration ihtiyaçları baştan tasarlanmalıdır.

Cassandra

Cassandra yüksek write throughput ve distributed scale için uygun access pattern'leri destekler. Partition key tenant ve entity tasarımına göre seçilir. Cross-partition query maliyetlidir. Data model relational database mantığından farklıdır. Tenant size skew hot partition riskine karşı izlenmelidir.

Veri Modeline Göre Seçim

Strong relational integrity ve complex transaction önemliyse SQL doğal avantaj sağlar. Document-heavy flexible schema farklı sistemleri uygun hale getirebilir. Technology trend yerine gerçek query ve update pattern incelenmelidir. Tenant restore ve migration tooling de selection kriteridir. Prototype benchmark gerçek workload ile yapılmalıdır.

Consistency Gereksinimine Göre Seçim

Finansal veya inventory işleminde strong consistency gerekebilir. Analytics veya event feed eventual consistency tolere edebilir. Tenant isolation consistency modelinden bağımsız güvenlik gereksinimidir. Distributed database conflict behavior business domain ile uyumlu olmalıdır. Transaction boundary seçimi data corruption riskini etkiler.

PostgreSQL Multi-Tenant Sistemlerde Neden Popülerdir?

PostgreSQL relational integrity ile gelişmiş database özelliklerini aynı platformda sunması nedeniyle multi-tenant SaaS projelerinde güçlü bir seçenektir. Row-Level Security shared schema izolasyonuna database-level koruma ekler. Schema, transaction, partitioning ve indexing özellikleri farklı tenancy modellerini destekler. JSONB gerektiğinde esnek data model sunar. Logical replication ve geniş açık kaynak ekosistemi migration ve operasyon araçları geliştirmeyi kolaylaştırır.

Row-Level Security

RLS tenant satırlarını database seviyesinde filtreleyebilir. Application filter unutulduğunda ikinci savunma katmanı sağlar. Runtime role doğru tasarlanmalıdır. Policy performance indexlerle desteklenmelidir. Otomatik isolation testleri zorunludur.

Schema

PostgreSQL schema namespace özelliği schema-per-tenant modelini mümkün kılar. Shared global ve tenant-specific schema ayrılabilir. Search path connection state dikkatle yönetilmelidir. Çok sayıda schema migration automation gerektirir. Model tenant sayısına göre değerlendirilmelidir.

Transaction

ACID transaction business consistency için güçlü temel sağlar. RLS tenant context SET LOCAL ile transaction-scoped tutulabilir. Multi-step operations atomik yapılabilir. Long transaction noisy neighbor riskini artırabilir. Transaction boundary business use case'e göre kısa tutulmalıdır.

Indexing

Composite index tenant-first query pattern'lerine uygun tasarlanabilir. Partial ve expression index gelişmiş ihtiyaçları destekler. Query planner gerçek tenant data dağılımına göre izlenmelidir. Concurrent index creation migration riskini azaltabilir. Index cost write workload ile dengelenmelidir.

Partitioning

Large tenant tables hash veya range partition ile yönetilebilir. Partition pruning performance avantajı sağlar. Partition security yerine geçmez. Tenant ID partition strategy'nin bir parçası olabilir. Partition count planning overhead yaratmayacak düzeyde tutulmalıdır.

JSONB

JSONB tenant-specific flexible metadata için kullanılabilir. Her tenant için schema fork oluşturma ihtiyacını azaltabilir. Critical query alanları normal kolon olarak tutulabilir. JSONB index ve validation stratejisi gerektirir. Core business relation'ları tamamen document içine gömmek her zaman doğru değildir.

Extensions

PostgreSQL extension ekosistemi monitoring, search ve utility özellikleri sunabilir. Production extension seçimi maintenance ve upgrade compatibility açısından değerlendirilmelidir. Tenant isolation extension behavior'ına bağlı bırakılmamalıdır. Security review yapılmalıdır. Managed environment hangi extension'ları destekliyor kontrol edilmelidir.

Logical Replication

Logical replication tenant migration, CDC ve analytics pipeline için kullanılabilir. Shared database'den dedicated database'e promotion sırasında değişiklik akışı taşınabilir. Filter capability ve operational overhead değerlendirilmelidir. Replication lag monitoring gerektirir. Cutover consistency test edilmelidir.

ORM ile Multi-Tenant Database Tasarımı

ORM multi-tenant query scoping'i kolaylaştırabilir fakat yanlış güven oluşturabilir. Global query filter veya middleware sayesinde tenant predicate otomatik uygulanabilir. Raw SQL, bulk operation ve admin bypass path'leri ayrıca kontrol edilmelidir. ORM'ın generated migration ve composite key desteği tenancy modelini etkiler. Database RLS ile birlikte kullanıldığında ORM filter developer ergonomisi, RLS ise güvenlik savunması sağlar.

Entity Framework Core

Global query filters tenant-scoped entity'lere otomatik predicate uygulamak için kullanılabilir. DbContext request tenant context'i taşıyabilir. Bypass API'leri admin path ile sınırlandırılmalıdır. Raw SQL ayrı test edilmelidir. Composite key ve migration behavior tenancy modeline göre doğrulanmalıdır.

Hibernate

Hibernate filter veya multi-tenancy mekanizmaları farklı storage modellerinde kullanılabilir. Session tenant identifier dikkatle yönetilmelidir. Connection pooling schema switching riskini etkiler. Native query ORM filter'ını bypass edebilir. Integration test gerçek runtime configuration kullanmalıdır.

Prisma

Prisma middleware veya extension yaklaşımı tenant filter eklemek için kullanılabilir. Client-generated query'nin tenant context olmadan çalışması engellenebilir. Raw query kullanımına ekstra kontrol gerekir. Database RLS ek savunma sağlayabilir. Generated schema migration composite tenant constraints ile test edilmelidir.

SQLAlchemy

SQLAlchemy session ve query event'leri tenant scoping için özelleştirilebilir. Request-scoped session trusted tenant context taşımalıdır. Raw SQL execution wrapper üzerinden sınırlandırılabilir. Schema-per-tenant search path transaction başlangıcında ayarlanabilir. Connection pool state leakage test edilmelidir.

Django ORM

Custom manager veya queryset tenant filter'ını merkezi hale getirebilir. Request middleware active tenant belirler. Developer'ın default manager yerine unsafe manager kullanması engellenmelidir. Database RLS defense in depth sunabilir. Management command ve background task tenant context'i ayrıca ele almalıdır.

Laravel Eloquent

Global scope tenant predicate otomatik ekleyebilir. Model creation sırasında tenant ID trusted context'ten set edilebilir. Scope bypass yalnızca explicit admin use case'e ayrılmalıdır. Queue job'lar tenant context taşımalıdır. Raw query builder kullanımında ekstra kontroller gerekir.

Global Query Filters

Global filter developer'ın her sorguda tenant condition yazma ihtiyacını azaltır. Bu ergonomi hata oranını düşürür. Fakat filter disable API veya raw SQL güvenlik boşluğu oluşturabilir. Security-sensitive code review gerekli olabilir. RLS ikinci katman sağlar.

ORM Filter'ına Tek Başına Güvenmemenin Riski

ORM filter sadece ORM üzerinden geçen query'lere uygulanır. Migration script, background job veya raw SQL farklı yol kullanabilir. Framework upgrade filter behavior'ını etkileyebilir. Database constraint ve RLS application dışı koruma sağlar. Isolation testleri tüm data access yollarını kapsamalıdır.

Mikroservislerde Multi-Tenancy

Mikroservis mimarisinde her service'in tenancy modelini bağımsız seçme ihtiyacı olabilir. Billing service dedicated storage kullanırken notification service shared model kullanabilir. Önemli olan tenant context'in service sınırlarında kaybolmamasıdır. Event ve distributed trace metadata tenant ID taşımalıdır. Servisler arası iletişim, keşif ve operasyon yaklaşımını derinleştirmek isteyenler https://www.diyarbakiryazilim.com.tr/posts/api-dokumantasyonunda-swagger-kullanimi-ve-standardizasyon adresindeki API standardizasyonu içeriğini de inceleyerek servis sözleşmelerini daha düzenli hale getirebilir.

Her Servis Aynı Tenancy Modelini Kullanmalı mı?

Hayır, her servis aynı data ve compliance gereksinimine sahip değildir. Auth service global user identity tutabilirken project service shared schema kullanabilir. Billing data daha sıkı isolation isteyebilir. Farklı model kullanılsa bile tenant ID semantics ortak olmalıdır. Platform standardı context propagation ve audit kurallarını tanımlamalıdır.

Service-Based Isolation

Bazı servisler tenant başına database kullanırken diğerleri shared olabilir. Domain boundary storage kararını etkiler. Service owner migration ve backup policy'den sorumludur. Tenant directory gerekiyorsa service-specific location metadata tutabilir. Business logic başka servisin storage modeline bağımlı olmamalıdır.

Shared Auth Service

Authentication service global users ve memberships yönetebilir. Token içinde trusted tenant claims üretir. Tenant switch membership doğrulamasından geçer. Downstream services token ve service identity'yi verify eder. Authorization permission domain service içinde ayrıca değerlendirilebilir.

Dedicated Billing Data

Billing data finansal önem nedeniyle daha farklı isolation ve audit policy alabilir. Tenant payment references shared operational tables'dan ayrılabilir. Service-to-service access minimum yetkiyle sınırlandırılır. Data retention financial requirements'a göre yönetilir. Cross-service reporting warehouse üzerinden yapılabilir.

Tenant Context Propagation

Service request header veya token tenant ID taşıyabilir. Downstream service yalnızca trusted internal caller'dan gelen context'i kabul etmelidir. User-controlled arbitrary header yeniden doğrulanmalıdır. Distributed trace tenant ID metadata'yı güvenli biçimde taşıyabilir. Service boundary'de context kaybı integration tests ile yakalanmalıdır.

Event'lerde Tenant ID

Domain event envelope tenant ID field içermelidir. Producer trusted current context'ten değeri ekler. Consumer tenant state ve resource ownership doğrulayabilir. Event replay aynı tenant mapping'i korumalıdır. Global event'ler explicit global scope ile ayrılmalıdır.

Distributed Trace İçinde Tenant Metadata

Trace span tenant ID veya privacy-safe tenant hash taşıyabilir. Incident sırasında hangi tenant'ın hangi service path'inde hata yaşadığı görülür. High cardinality cost göz önünde bulundurulmalıdır. Public trace export hassas customer isimlerini içermemelidir. Support troubleshooting önemli ölçüde kolaylaşır.

Event-Driven Sistemlerde Tenant İzolasyonu

Event-driven mimaride tenant context HTTP request'ten çıktıktan sonra message envelope içinde korunmalıdır. Producer trusted tenant ID ekler ve consumer bu metadata'yı doğrular. Topic veya queue tenant başına ayrılabilir ya da shared queue içinde tenant field kullanılabilir. Replay ve dead letter süreçleri aynı isolation kuralına uymalıdır. Event payload içindeki client-controlled tenant değeri security context yerine geçmemelidir.

Event Envelope

Envelope event ID, tenant ID, type ve version gibi metadata içerir. Business payload'dan ayrı tutulması parsing ve security control'ü kolaylaştırır. Schema registry tenant ID alanını required yapabilir. Global platform event'leri explicit scope gösterebilir. Event ID idempotency için kullanılır.

tenant_id

Tenant field producer'ın trusted execution context'inden gelir. Consumer routing ve repository scope için kullanır. Missing veya invalid tenant message reject veya quarantine edilir. Tenant ID logging privacy policy'ye uygun yapılır. Replay sırasında original tenant korunur.

Producer

Producer event'i business transaction ile tutarlı biçimde yayınlamalıdır. Outbox pattern kullanılabilir. Tenant ID application context'ten otomatik eklenir. Developer payload içine manuel tenant yazmamalıdır. Event serialization security testlerden geçer.

Consumer

Consumer message tenant context'i ile scoped processing başlatır. Database connection doğru tenant'a yönlendirilir. Concurrent messages global mutable state paylaşmamalıdır. Retry context'i korur. Tenant state deleted ise message policy'ye göre atlanabilir.

Topic/Queue Isolation

Shared topic çok sayıda tenant için operasyonel olarak basittir. Tenant-per-topic daha güçlü isolation sunabilir fakat topic sayısı büyür. Enterprise customer için dedicated queue düşünülebilir. ACL ve encryption policy seçimi etkiler. Routing key tenant ID içerebilir.

Tenant Context Validation

Consumer tenant ID'nin varlığını ve formatını kontrol eder. Hassas işlemde tenant directory state doğrulanabilir. Resource payload tenant ile uyuşmuyorsa event reject edilir. Cross-tenant event relationship güvenlik alert'i olabilir. Validation reusable middleware haline getirilebilir.

Dead Letter Queue

Failed event original tenant metadata ile DLQ'ya gider. Support access payload'a sınırlı olmalıdır. Replay tenant context'i yeniden oluşturur. Deleted tenant event'i tekrar işlenmemelidir. DLQ retention data policy'ye uymalıdır.

Replay Sırasında Tenant Güvenliği

Historical event replay geniş data range işleyebilir. Replay tool cross-tenant admin capability olduğu için yüksek yetki taşır. Tenant scope seçimi explicit ve audit edilmelidir. Rate limit production workload'u korur. Replay event'leri duplicate effect yaratmaması için idempotent olmalıdır.

Multi-Tenant API Tasarımı

Multi-tenant API tenant context'i açık ve güvenilir biçimde çözen bir sözleşmeye ihtiyaç duyar. Subdomain, path, API key veya authentication token farklı yöntemler sunabilir. Client tarafından gönderilen tenant bilgisi membership doğrulamasından geçmeden trusted kabul edilmemelidir. Rate limit ve quota tenant bazında uygulanabilir. Audit log request'in actor ve tenant context'ini birlikte kaydetmelidir.

Tenant-Specific Subdomain

Subdomain tenant seçimini kullanıcıya görünür hale getirir. DNS wildcard veya custom domain routing kullanılabilir. Host tenant directory üzerinden resolve edilir. Authentication user membership'i doğrular. Subdomain collision ve takeover riskleri provisioning'de kontrol edilmelidir.

Tenant Path

/tenants/{id}/... veya organization slug path içinde taşınabilir. API debugging kolaydır. Client path ID'yi değiştirebilir, bu nedenle authorization zorunludur. Resource query active tenant context ile scope edilir. Nested paths ownership kontrolünü kolaylaştırabilir.

API Key

API key tenant-specific integration identity olarak kullanılabilir. Key lookup tenant ID ve permission set döndürür. Client ayrıca tenant ID göndermek zorunda olmayabilir. Rate limit key veya tenant bazında uygulanabilir. Rotation ve revocation lifecycle ile yönetilmelidir.

Authentication

User veya service identity doğrulanır. Token issuer, expiration ve signature kontrol edilir. Tenant access ayrıca membership veya credential relation ile belirlenir. Authentication response active tenant seçeneklerini sunabilir. Session switch güvenli biçimde yapılmalıdır.

Tenant Resolution

Tenant resolver request sinyallerini trusted tenant context'e çevirir. Subdomain, path ve token çelişiyorsa request reddedilebilir. Directory tenant state kontrolü yapar. Middleware sonucu immutable context olarak taşır. Repository yalnızca bu context'i kullanır.

Rate Limit Per Tenant

Rate limit user yerine tenant toplam workload'u üzerinde uygulanabilir. Bir tenant çok sayıda user ile global quota'yı aşmamalıdır. Plan tier farklı quota verebilir. Burst ve sustained limits ayrı tutulabilir. 429 response retry bilgisini açıkça sunmalıdır.

Quota

Storage, API call, job veya export quota product plan ile ilişkilendirilebilir. Usage tenant bazında ölçülür. Soft threshold warning, hard threshold enforcement uygulanabilir. Enterprise custom quota desteklenebilir. Quota exceed başka tenant'ları etkilememelidir.

API Audit Log

Kritik API action actor, tenant, endpoint ve resource ID ile loglanmalıdır. Raw sensitive payload gereksiz tutulmamalıdır. Support ve admin calls ayrı işaretlenir. Audit customer-facing feature olabilir. Retention ve tamper protection politika gerektirir.

Shared Schema vs Schema-Per-Tenant vs Database-Per-Tenant

Shared database shared schema ve database per tenant karşılaştırması tek bir “hangisi daha iyi?” sorusuyla çözülemez. Shared schema en düşük operasyon maliyeti ve yüksek tenant yoğunluğu sağlarken database-per-tenant en güçlü tenant-level restore ve isolation imkanlarından birini sunar. Schema-per-tenant iki yaklaşım arasında namespace ayrımı sağlar fakat migration fan-out maliyeti taşır. Çoklu kiracılı veritabanlarında ölçeklenebilirlik performans ve veri izolasyonu birlikte değerlendirilmelidir. Büyüyen SaaS sistemlerinde hybrid model çoğu zaman farklı müşteri segmentlerinin ihtiyaçlarını daha ekonomik karşılar.

İzolasyon

Shared schema logical row-level isolation kullanır. Schema-per-tenant namespace boundary ekler. Database-per-tenant storage boundary'yi daha açık hale getirir. Her modelde application authorization yine gereklidir. Enterprise compliance isolation seviyesini belirleyebilir.

Maliyet

Shared schema kaynak paylaşımı nedeniyle en düşük birim maliyete yaklaşır. Separate schema aynı database maliyetini paylaşır fakat operasyon yükü artar. Dedicated database tenant sayısıyla altyapı maliyetini büyütebilir. Automation engineering cost'u azaltır. Pricing model isolation tier maliyetini karşılamalıdır.

Operasyonel Karmaşıklık

Shared schema tek migration ve pool ile en sade modeldir. Schema-per-tenant migration fan-out gerektirir. Database-per-tenant provisioning, credentials ve pools daha fazla orchestration ister. Hybrid model routing katmanı ekler. Operasyon ekibi kapasitesi model seçiminin gerçek kriterlerinden biridir.

Ölçeklenebilirlik

Shared schema birçok küçük tenant'a rahat ölçeklenir. Tek database limitine yaklaşınca sharding gerekir. Schema-per-tenant catalog ve migration ölçeği sorun olabilir. Database-per-tenant yatay dağılımı doğal yapar fakat control plane ölçeklenmelidir. Hybrid model büyük tenant'ı ayrı storage'a çıkarabilir.

Migration

Shared schema migration tek yerde uygulanır. Separate schema her tenant schema'sında tekrar çalışır. Database-per-tenant her database için orchestrator gerektirir. Canary ve expand-and-contract tüm modellerde değerlidir. Data migration future architecture değişimine hazır olmalıdır.

Backup

Shared schema full backup basittir ama tenant-level recovery zorlaşır. Schema-per-tenant schema dump avantajı sunabilir. Database-per-tenant independent backup en açık modeldir. Backup encryption tüm modellerde gereklidir. RPO tier'e göre değişebilir.

Restore

Shared database'de tek tenant restore extraction ve merge gerektirir. Separate schema restore daha doğal olabilir. Dedicated database tenant bağımsız restore sağlar. Restore süresi gerçek drill ile ölçülmelidir. Product SLA bu farkı fiyatlandırabilir.

Analytics

Shared schema cross-tenant analytics teknik olarak kolaydır. Schema ve database ayrımı fan-out query ihtiyacı yaratır. Büyük sistemde data warehouse zaten daha sağlıklı çözümdür. Tenant ID pipeline boyunca korunmalıdır. Customer analytics isolation her modelde devam eder.

Customization

Schema-per-tenant tenant-specific schema değişikliklerine izin verebilir fakat uzun vadede drift yaratır. Shared model metadata ve feature configuration ile daha sürdürülebilir olabilir. Dedicated database custom extension için daha güvenli alan sağlayabilir. Customization contract ve migration cost ile sınırlandırılmalıdır. Her müşteri için farklı schema ürün bakımını zorlaştırır.

Compliance

Dedicated database data residency ve tenant-specific key gereksinimlerini daha kolay karşılayabilir. Shared schema da güçlü RLS ve encryption ile birçok kullanım için yeterli olabilir. Compliance gereksinimi müşteri ve sektör bazında değerlendirilmelidir. Audit ve restore capability teknik model kadar önemlidir. Hukuki gereksinimler güncel uzmanlıkla doğrulanmalıdır.

Noisy Neighbor

Shared modelde risk en yüksektir. Schema ayrımı aynı database resource'u paylaştığı için sorunu tamamen çözmez. Dedicated database resource boundary'yi güçlendirir. Rate limit ve query control tüm modellerde yararlıdır. Monitoring tenant SLO üzerinden yapılmalıdır.

Provisioning Hızı

Shared schema tenant creation birkaç row insert ile tamamlanabilir. Schema-per-tenant DDL ve migration gerektirir. Database-per-tenant resource provisioning daha uzun sürebilir. Automation bu farkı azaltır. User onboarding experience asynchronous provisioning state gösterebilir.

Multi-Tenant Database Modeli Nasıl Seçilir?

Model seçimi tenant sayısı, tenant başına veri hacmi, compliance, restore ve data residency gereksinimleriyle birlikte yapılmalıdır. En büyük tenant boyutu özellikle önemlidir, çünkü ortalama değer noisy neighbor riskini gizler. Operasyon ekibinizin database provisioning ve migration otomasyonu geliştirme kapasitesi de teknik tercih kadar belirleyicidir. Cross-tenant analytics veya custom schema ihtiyacı modeli etkileyebilir. Gereksiz fiziksel izolasyonla başlamak yerine migration yolu açık bir shared veya hybrid model çoğu SaaS için daha dengeli olur.

Kaç Tenant Olacak?

On tenant ile on bin tenant aynı operasyon modelini gerektirmez. Tenant sayısı schema veya database object sayısını doğrudan etkiler. Binlerce database güçlü automation olmadan yönetilemez. Shared schema yüksek tenant count için ekonomiktir. Gelecek üç ila beş yıllık tahmin kullanılmalıdır.

Tenant Başına Veri Miktarı Ne Kadar?

Küçük tenant'lar ortak pool için uygundur. Tenant başına yüzlerce GB data shared index ve backup davranışını değiştirebilir. Storage growth trend hesaplanmalıdır. Object storage ve search size da dahil edilmelidir. Promotion threshold belirlenebilir.

En Büyük Tenant Ne Kadar Büyük?

Average tenant yerine maximum tenant tasarım sınırlarını belirleyebilir. En büyük customer CPU, storage ve query pattern'i ayrı test edilmelidir. Dedicated database ekonomik hale gelebilir. Contract pipeline tenant promotion'ı desteklemelidir. Capacity planning bu tenant'ın iki kat büyüdüğü senaryoyu değerlendirebilir.

Compliance Gereksinimi Var mı?

Regülasyon ayrı database, region veya key gerektirebilir. Her müşterinin aynı requirement'a sahip olduğu varsayılmamalıdır. Isolation tier compliance ihtiyacını ürünleştirir. Audit ve restore süreçleri de değerlendirilmelidir. Teknik karar hukuki değerlendirmeyle birlikte yapılmalıdır.

Tenant Bazında Restore Gerekli mi?

Customer yanlışlıkla data sildiğinde yalnızca kendi verisini geri istemesi yaygın senaryodur. Shared schema'da bu operasyon daha zordur. Dedicated database tenant PITR avantajı sağlar. Restore RTO sözleşmenin parçasıysa model üzerinde büyük etkisi vardır. Prototype restore drill seçim öncesinde yapılabilir.

Data Residency Gerekli mi?

Tenant data belirli region veya country içinde tutulacaksa directory-based routing gerekir. Dedicated database veya regional shards işi kolaylaştırır. Shared global database bu requirement'ı karşılamayabilir. Backup ve analytics de aynı residency policy'ye uymalıdır. Region migration future requirement olarak düşünülmelidir.

Tenant Bazında Custom Schema Gerekli mi?

Her tenant farklı kolon veya table istiyorsa shared schema zorlanabilir. Fakat custom JSON veya extension model daha sürdürülebilir olabilir. Schema-per-tenant customization kolay görünür fakat migration drift'i büyür. Dedicated database enterprise customization için daha kontrollü olabilir. Product uzun vadede hangi customization'ları gerçekten destekleyeceğini sınırlamalıdır.

Cross-Tenant Analytics Gerekli mi?

Platform-wide dashboard ve benchmark isteniyorsa shared schema kısa vadede kolaylık sağlar. Dedicated database modelde data warehouse pipeline gerekir. Büyüyen sistemlerde warehouse zaten OLTP'den daha iyi seçenektir. Tenant ID analytics lineage'da korunmalıdır. Compliance aggregate data usage'ını etkileyebilir.

Operasyon Ekibiniz Ne Kadar Büyük?

Database-per-tenant güçlü automation ve platform engineering ihtiyacı doğurur. Küçük ekip manual provisioning ile zorlanabilir. Shared schema daha az operasyon overhead sağlar. Managed database servisleri yükü azaltabilir fakat lifecycle tooling yine gerekir. Mimari mevcut insan kapasitesine uyumlu olmalıdır.

Karar Matrisi: Hangi Model Ne Zaman?

Karar matrisi tenancy modelini iş ve teknik bağlama göre değerlendirmeyi kolaylaştırır. Erken aşama SaaS ve çok sayıda küçük tenant çoğu zaman shared schema ile başarılı başlayabilir. B2B orta ölçekli tenant'larda schema-per-tenant bazı ihtiyaçları karşılayabilir. Büyük enterprise ve regülasyon odaklı projelerde database-per-tenant veya hybrid yaklaşım daha güçlüdür. Analytics-heavy ürünler storage modelinden bağımsız warehouse yatırımı gerektirir.

Erken Aşama SaaS

Ürün-market uyumu henüz net değilken gereksiz infrastructure ayrımı geliştirme hızını düşürebilir. Shared schema iyi bir başlangıçtır. Tenant context ve RLS baştan doğru tasarlanmalıdır. Migration path business logic'ten ayrılmalıdır. Büyüdükçe hybrid modele geçilebilir.

Çok Sayıda Küçük Tenant

Pool model en yüksek resource verimliliğini sağlar. Provisioning neredeyse anlıktır. Shared index ve cache ekonomik olur. Rate limit noisy neighbor riskini azaltır. Tenant-level restore tooling ayrıca geliştirilmelidir.

Orta Sayıda B2B Tenant

Shared schema veya schema-per-tenant ikisi de uygun olabilir. Compliance ve restore beklentisi karar verir. Schema count operasyon ekibinin kaldırabileceği seviyede olmalıdır. Enterprise growth ihtimali hybrid path gerektirir. Customer usage dağılımı düzenli izlenmelidir.

Az Sayıda Büyük Enterprise Tenant

Dedicated database güçlü tercih olabilir. Tenant başına gelir maliyeti karşılar. Performance tuning ve restore ayrı yapılabilir. Custom region veya key desteklenebilir. Provisioning ve migration automation yine zorunludur.

Finans ve Regülasyon

Data access audit ve strict isolation daha yüksek öncelik alır. Dedicated database veya dedicated region değerlendirilebilir. Encryption key ve backup policy tenant-specific olabilir. Support access JIT ve approval kullanmalıdır. Compliance requirement teknik tasarım belgesine açıkça işlenmelidir.

Analytics-Heavy SaaS

Ağır rapor workload OLTP tenant'larını etkilememelidir. Shared veya dedicated storage olsa da warehouse gerekir. Event streaming veya ETL tenant ID'yi korumalıdır. Pre-aggregation customer dashboard'u hızlandırır. Resource cost attribution analytics tenant'larını ayrıca izleyebilir.

Tenant Bazında Özelleştirme

Customization yalnızca feature flag ise shared schema yeterlidir. Data model kökten farklıysa dedicated storage daha güvenli olabilir. Schema-per-tenant küçük extension için kullanılabilir fakat drift kontrolü gerekir. Core schema mümkün olduğunca ortak tutulmalıdır. Product support maliyeti customization sınırını belirlemelidir.

Hibrit Mimarinin Daha Mantıklı Olduğu Durumlar

Tenant boyutu veya compliance gereksinimleri çok farklıysa tek model tüm müşterilere uymaz. Shared pool standard müşteri için maliyet avantajı sağlar. Enterprise tenant dedicated database'e taşınabilir. Tenant directory ve repository abstraction bu geçişi kolaylaştırır. Hybrid yapı isolation tier'i ürün stratejisine bağlar.

Mimariyi Gelecekteki Migration'a Hazırlamak

Başlangıçta shared schema seçmek ileride database-per-tenant modele geçilemeyeceği anlamına gelmemelidir. Storage modelini business logic'ten ayırmak ve tenant-aware repository kullanmak migration esnekliği sağlar. Tenant directory başlangıçta basit olsa bile future routing için temel oluşturabilir. Tenant ID tüm data ve event katmanlarında korunmalıdır. Export, verification ve migration tooling erken geliştirilirse büyük enterprise tenant geldiğinde platformu yeniden yazmak gerekmez.

Storage Modelini Business Logic'ten Ayırmak

Service layer database topology bilmemelidir. Repository interface tenant-scoped operations sunar. Shared ve dedicated adapters aynı contract'ı uygular. Böylece tenant promotion storage configuration değişikliği olur. Test suite tüm adapter'lar için aynı behavior'ı doğrular.

Tenant-Aware Repository

Repository trusted tenant context olmadan çalışmamalıdır. Shared schema filter, schema selection veya database routing içeride çözülür. Cross-tenant admin interface ayrı tutulur. Bu abstraction data migration sırasında dual source kullanımını da kolaylaştırır. Performance critical query'ler storage-specific optimize edilebilir.

Tenant Directory

Başlangıçta tüm tenant'lar aynı database'de olsa bile directory mapping tutulabilir. Gelecekte shard veya region alanları eklenir. Business code sabit connection varsaymaz. Directory versioned ve audited olur. Cache ile low-latency routing sağlanır.

Dynamic Database Routing

Connection resolver tenant metadata'ya göre database seçebilir. İlk aşamada her tenant aynı endpoint'e yönlenir. Daha sonra enterprise tenant farklı endpoint alır. Application deployment değişmeden routing güncellenebilir. Resolver security-sensitive component olarak test edilmelidir.

Tenant ID'yi Her Katmana Taşımak

Database, cache, event, storage ve trace tenant ID'yi ortak identifier olarak kullanmalıdır. Bu consistency migration ve debugging'i kolaylaştırır. Tenant ID client-controlled değil trusted context'ten gelir. Analytics pipeline da aynı ID'yi korur. Data export tenant ownership'ı bu alandan belirler.

Migration Tooling

Tenant data copy ve verification script'leri incident anında yazılmamalıdır. Staging tenant promotion testleri düzenli yapılabilir. CDC veya dual-write abstraction hazır olabilir. Migration dashboard progress gösterir. Rollback ve cleanup adımları automation içinde bulunmalıdır.

Data Export

Tenant export capability migration'ın temel yapı taşıdır. Shared database'den tenant rows güvenli biçimde çıkarılabilmelidir. Object storage ve search data da paketlenmelidir. Export integrity test edilmelidir. Bu tooling customer portability için de kullanılabilir.

Tenant-Level Verification

Source ve target tenant data business invariant'larla karşılaştırılmalıdır. Yalnızca row count yeterli değildir. Aggregate, checksum ve sample queries kullanılabilir. Application smoke test target storage'da çalıştırılır. Verification reusable library haline getirilebilir.

Multi-Tenant Database Tasarımında Sık Yapılan Hatalar

Multi-tenant sistemlerde en büyük hatalar çoğu zaman temel izolasyon varsayımlarının yanlış kurulmasından kaynaklanır. Tenant filtresini developer'ın hatırlamasına bırakmak, request body tenant ID'sine güvenmek veya cache key'inde tenant bilgisini unutmak ciddi risk yaratır. Backup alınmasına rağmen tenant restore'un hiç test edilmemesi de sık görülen operasyondur. Büyük tenant için hiçbir plan olmaması noisy neighbor sorununu büyütür. Doğru yaklaşım güvenliği, restore'u ve migration'ı en baştan otomatik sistem davranışı haline getirmektir.

Tenant ID Filtresini Developer'ın Hatırlamasına Bırakmak

Manual filter insan hatasına açıktır. Bir yeni endpoint veya raw SQL filtreyi unutabilir. Repository global scope ve RLS bu riski azaltır. Code review tek başına yeterli değildir. Isolation integration testleri sürekli çalışmalıdır.

Tenant ID'yi Request Body'den Güvenmek

Client request'i kolayca değiştirebilir. Tenant ownership server trusted context'ten gelmelidir. Membership doğrulaması zorunludur. RLS wrong-tenant write'ı engelleyebilir. Request payload tenant ID yalnızca admin import gibi özel durumda açıkça doğrulanmalıdır.

RLS Olmadan Hassas Shared Schema Kullanmak

Application filter tek savunma olduğunda tek bug data leak'e dönüşebilir. Hassas B2B data için RLS güçlü ikinci katmandır. Runtime role doğru yapılandırılmalıdır. Policy performance test edilmelidir. RLS kullanılamıyorsa eşdeğer database-level guardrail düşünülmelidir.

Runtime Database User'ı Fazla Yetkili Yapmak

Superuser veya table owner application credential olarak kullanılmamalıdır. RLS bypass ve DDL yetkisi blast radius'u büyütür. Runtime role minimum CRUD permission taşımalıdır. Migration role ayrı tutulur. Secret manager erişimi identity bazında sınırlandırılır.

Unique Constraint'leri Tenant-Aware Tasarlamamak

Global unique constraint farklı tenant'ların aynı business value kullanmasını engelleyebilir. Ayrıca başka tenant'ta değer bulunduğunu dolaylı biçimde gösterebilir. Composite unique doğru semantics sağlar. Global unique alanlar açıkça sınıflandırılmalıdır. Constraint migration data cleanup ile birlikte yapılmalıdır.

Cache Key'lerinde Tenant ID Kullanmamak

Resource ID tek başına cache key olduğunda cross-tenant collision oluşabilir. Tenant prefix standardı zorunlu hale getirilmelidir. Helper library raw key usage'ı azaltır. Test aynı ID ile iki tenant response'unu karşılaştırır. CDN private cache policy de kontrol edilmelidir.

Background Job'larda Tenant Context'i Kaybetmek

HTTP request'ten queue'ya geçerken tenant metadata unutulabilir. Worker global database connection ile yanlış tenant'ta işlem yapabilir. Message envelope trusted tenant ID taşımalıdır. Worker her job için fresh context oluşturmalıdır. Retry ve DLQ aynı bilgiyi korumalıdır.

Per-Tenant Restore'u Düşünmemek

Full backup almak tenant restore garantisi değildir. Shared database recovery extraction ve merge gerektirir. Runbook ve script önceden hazırlanmalıdır. Düzenli restore test yapılmalıdır. RTO gerçek süre üzerinden hesaplanmalıdır.

Noisy Neighbor'ı İzlememek

Global database metrics tenant-specific etkiyi gizler. Latency ve workload tenant boyutuyla ilişkilendirilmelidir. Heavy query ve connection flood testleri yapılmalıdır. Rate limit ve workload queue uygulanabilir. Büyük tenant promotion threshold belirlenmelidir.

En Büyük Tenant İçin Plan Yapmamak

Ortalama tenant'a göre tasarlanan sistem büyük customer geldiğinde zorlanabilir. En büyük dataset ve QPS benchmark edilmelidir. Dedicated database migration yolu açık tutulmalıdır. Cost attribution promotion kararını destekler. Enterprise sales teknik kapasite sınırlarını bilmelidir.

Migration Stratejisi Olmadan Schema-Per-Tenant Kullanmak

İlk birkaç tenant ile migration kolay görünür. Tenant sayısı yüzlere ulaştığında fan-out operasyonu sorun olur. Orchestrator, schema version ve retry baştan planlanmalıdır. Canary rollout kullanılmalıdır. Custom schema drift mümkün olduğunca sınırlandırılmalıdır.

Database-Per-Tenant'ı Otomasyon Olmadan Yönetmeye Çalışmak

Manual database creation ve migration tenant sayısı arttıkça sürdürülemez. Credential ve backup drift oluşur. Provisioning state machine şarttır. Migration dashboard ve pool management otomatik olmalıdır. Platform engineering maliyeti modele baştan dahil edilmelidir.

Production Öncesi Multi-Tenant Database Kontrol Listesi

Production'a çıkmadan önce tenant tanımı, context kaynağı, database scoping, backup, restore, cache ve worker isolation birlikte kontrol edilmelidir. Yalnızca application happy path testleri yeterli değildir. Runtime database role ve RLS bypass davranışı özellikle doğrulanmalıdır. Tenant-aware unique ve foreign key constraint'ler data integrity'yi güçlendirir. Gelecekte farklı isolation modeline migration yolu bulunması büyüyen SaaS için önemli bir hazırlıktır.

Tenant Tanımı Net mi?

Tenant şirket mi, workspace mi yoksa project mi olduğu açık olmalıdır. Billing ve data ownership sınırı tanımlanmalıdır. User ile tenant ayrılmalıdır. Multi-membership modeli değerlendirilmelidir. Tüm ekip aynı terminology'yi kullanmalıdır.

Tenant Context Güvenilir Kaynaktan mı Geliyor?

Request body veya raw header doğrudan trusted kabul edilmemelidir. Authentication ve membership üzerinden server context üretilmelidir. Middleware merkezi resolution yapmalıdır. Background job aynı context'i güvenli metadata'dan almalıdır. Invalid context default-deny olmalıdır.

Her Tenant Table'ı Scope Ediliyor mu?

Tenant-scoped tablolar açık ownership bilgisi taşımalıdır. Repository query filter zorunlu olmalıdır. Global table'lar ayrı sınıflandırılmalıdır. Child entity tenant integrity korunmalıdır. New table review checklist bu soruyu içermelidir.

RLS Gerekiyor mu?

Hassas shared schema sistemlerinde RLS güçlü savunma sağlar. Risk ve database capability değerlendirilmelidir. Policy maintenance maliyeti hesaba katılmalıdır. Application filter yine kullanılabilir. Security-critical tablolar öncelikli olabilir.

Runtime Role RLS'yi Bypass Ediyor mu?

Application credential table owner veya BYPASSRLS olmamalıdır. Production permission test edilmelidir. Migration user ayrı tutulmalıdır. FORCE RLS behavior gerekiyorsa doğrulanmalıdır. CI runtime role policy testleri çalıştırmalıdır.

Unique Constraint'ler Tenant-Aware mı?

Slug, email ve external ID'nin uniqueness scope'u açık olmalıdır. Tenant-specific alanlar composite unique kullanmalıdır. Global unique yalnızca gerçekten gerekli alanlarda olmalıdır. Error messages information leak yapmamalıdır. Existing data migration öncesi kontrol edilmelidir.

Foreign Key'ler Cross-Tenant İlişkiyi Engelliyor mu?

Child ve parent tenant ID eşleşmesi database tarafından doğrulanabilir. Composite foreign key değerlendirilebilir. Application validation ayrıca kalmalıdır. Raw SQL invalid relation oluşturamamalıdır. Integration test cross-tenant parent ID insert etmelidir.

Tenant-First Index'ler Var mı?

Common query pattern tenant ID ile başlıyorsa uygun composite index gerekir. En büyük tenant dataset'i ile explain plan incelenmelidir. Gereksiz duplicate index oluşturulmamalıdır. Sorting ve pagination index ile uyumlu olmalıdır. Query monitoring production feedback sağlar.

Cache Tenant-Aware mı?

Her tenant-scoped key tenant ID içermelidir. CDN ve in-memory cache de aynı kurala tabidir. Eviction başka tenant'ı etkilememelidir. Cross-tenant cache testleri yapılmalıdır. Global cache data açıkça ayrı namespace kullanmalıdır.

Worker ve Queue'lar Tenant-Aware mı?

Message envelope trusted tenant ID taşır. Worker fresh context oluşturur. Retry ve DLQ tenant bilgisi korur. Concurrent job'lar state paylaşmamalıdır. Worker isolation testleri CI'da bulunmalıdır.

Backup Var mı?

Full ve incremental backup policy tanımlanmalıdır. Encryption ve retention kontrol edilmelidir. Backup job failure alert üretmelidir. PITR hedefi RPO ile uyumlu olmalıdır. Backup erişimi minimum yetkiyle sınırlandırılmalıdır.

Tek Tenant Restore Test Edildi mi?

Shared database'de gerçek tenant extraction senaryosu denenmelidir. Restore süresi ölçülmelidir. File ve search data da kapsanmalıdır. Conflict resolution runbook bulunmalıdır. Sonuç RTO ile karşılaştırılmalıdır.

Offboarding Süreci Var mı?

Access revoke, export, retention ve deletion adımları tanımlanmalıdır. Search ve storage cleanup unutulmamalıdır. Credential revoke otomatik olmalıdır. Backup retention policy açık olmalıdır. Deletion audit üretilmelidir.

Cross-Tenant Leak Testleri CI'da mı?

Read, write, search, export ve file endpoint'leri düzenli test edilmelidir. Aynı resource ID collision fixture kullanılmalıdır. RLS default-deny test edilmelidir. Failure release'i durdurmalıdır. Yeni feature tenant isolation suite'e eklenmelidir.

Noisy Neighbor Test Edildi mi?

Heavy tenant workload altında küçük tenant SLO'ları ölçülmelidir. Query timeout ve rate limit doğrulanmalıdır. Connection saturation test edilmelidir. Background queue fairness kontrol edilmelidir. Promotion threshold metric'lerle desteklenmelidir.

Tenant Bazlı Monitoring Var mı?

Latency, size, error ve migration version tenant boyutuyla görülebilmelidir. High-cardinality metric cost yönetilmelidir. Enterprise tenant SLO ayrı dashboard alabilir. Alert noisy neighbor etkisini yakalamalıdır. Cost attribution aynı telemetry'den yararlanabilir.

Bir Sonraki Isolation Modeline Migration Yolu Var mı?

Shared schema'dan dedicated database'e geçiş teknik olarak mümkün olmalıdır. Tenant export ve directory mapping hazır olmalıdır. Business logic storage topology'den ayrılmalıdır. Data verification tooling bulunmalıdır. Future enterprise requirement geldiğinde full rewrite gerekmemelidir.

Uçtan Uca Örnek: PostgreSQL Shared Schema + RLS

Pratik bir shared schema tasarımında tenants, users, memberships ve projects tabloları kullanılabilir. Projects tablosu tenant ID taşır ve composite unique constraint tenant içindeki slug benzersizliğini korur. Tenant-first index sık kullanılan sorguları hızlandırır. PostgreSQL RLS runtime tenant context'e göre satır erişimini sınırlar. Request middleware ve repository filter birlikte çalışarak application ve database seviyesinde defense in depth oluşturur.

tenants Tablosu

Tenant ID, name, state ve plan bilgisi tutulur. Internal ID primary key olabilir. Public slug unique tutulabilir. Lifecycle state routing ve access policy'yi etkiler. Audit timestamps bulunmalıdır.

users Tablosu

Global user identity burada bulunur. Email identity policy'ye göre global unique olabilir. Tenant ID doğrudan user'a bağlanmak zorunda değildir. Membership ilişkisi multi-organization kullanımını destekler. Authentication metadata hassas biçimde saklanmalıdır.

memberships Tablosu

tenant_id, user_id ve role alanları bulunur. Composite unique duplicate membership'i engeller. Membership state active olmalıdır. Tenant switch bu tablo üzerinden doğrulanır. RLS gerekirse membership query'lerinde de uygulanabilir.

projects Tablosu

Her project tenant ID taşır. Project slug tenant içinde unique olabilir. Owner user membership doğrulaması application tarafından yapılır. RLS active tenant dışındaki project satırlarını gizler. Index tenant ve created_at üzerinden oluşturulabilir.

Composite Unique Constraint

UNIQUE(tenant_id, slug) farklı tenant'ların aynı project slug'ını kullanmasına izin verir. Aynı tenant duplicate oluşturamaz. Constraint database-level integrity sağlar. Error application tarafından domain-specific response'a dönüştürülür. Global unique yanlışlıkla kullanılmamalıdır.

Tenant-First Index

(tenant_id, created_at) project listesi için uygun olabilir. Pagination aynı sort order'ı kullanır. Tenant ID filter repository tarafından eklenir. Query plan büyük tenant dataset'inde incelenir. RLS predicate index kullanımını desteklemelidir.

RLS Policy

Policy row tenant ID ile transaction tenant setting'i karşılaştırır. SELECT ve write policy'leri ayrı tanımlanabilir. Context eksikse access reddedilir. Runtime role policy'ye tabi olur. CI Tenant A ve B session'larıyla doğrulama yapar.

Runtime Database Role

Application role table owner değildir. BYPASSRLS yetkisi yoktur. Yalnızca gerekli CRUD permission'ları bulunur. Migration ayrı role ile yapılır. Production secret manager credential'ı saklar.

Request Middleware

Authentication user identity'yi doğrular. Tenant resolver membership'i kontrol eder. Trusted tenant context request içine eklenir. Database transaction tenant setting ile başlatılır. Invalid tenant request repository'ye ulaşmaz.

Repository

Repository method'ları tenant context olmadan çağrılamaz. Query filter otomatik uygulanır. Raw SQL özel wrapper gerektirir. RLS filtre unutulsa bile ek savunma sağlar. Cross-tenant admin repository ayrı role kullanır.

Cross-Tenant Integration Test

Tenant A ve B aynı project slug veya numeric ID değerine sahip olabilir. A session B project ID ile GET yapar. Sonuç data döndürmemelidir. Update ve delete ayrıca denenir. Test application filter ve RLS katmanlarını birlikte doğrular.

Background Worker

Job message trusted tenant ID taşır. Worker transaction tenant context ile başlatılır. Repository normal request ile aynı scope davranışını kullanır. Retry context'i korur. Parallel A ve B job'ları state leakage testine tabi tutulur.

Uçtan Uca Örnek: Enterprise Tenant'ı Dedicated Database'e Taşımak

Enterprise tenant shared pool içinde büyüyüp SLO veya compliance sınırına ulaştığında dedicated database'e taşınabilir. İlk olarak target database provision edilir ve current schema uygulanır. Historical tenant data kopyalanırken incremental değişiklikler senkron tutulur. Verification tamamlandığında tenant directory yeni storage location'a çevrilir. Monitoring ve rollback window sonrası shared database'deki eski tenant verisi güvenli biçimde silinir.

Tenant'ı Belirlemek

Promotion kararı usage, cost ve compliance metric'lerine dayanabilir. Tenant owner ve migration window belirlenir. Data size ve dependent services inventory çıkarılır. Customer communication planlanır. Directory isolation tier migration state'e alınır.

Dedicated Database Provision Etmek

Target region ve cluster seçilir. Database, runtime role ve secret oluşturulur. Backup ve monitoring policy aktif edilir. Health check tamamlanır. Directory target location pending olarak saklanır.

Schema Migration

Target database current application schema version'a getirilir. Index ve constraints doğrulanır. RLS dedicated modelde gerekmese bile application role permission test edilir. Seed data uygulanır. Smoke query çalıştırılır.

Historical Data Copy

Source shared database'den yalnızca tenant rows export edilir. Dependency order korunur. Büyük tablolar chunk'lar halinde taşınır. Object storage ve search data ayrı stream olabilir. Progress metric kaydedilir.

Incremental Sync

Copy sırasında gelen yeni write'lar CDC veya event log ile target'a aktarılır. Lag izlenir. Idempotency duplicate apply riskini azaltır. Ordering kritik domain events için korunmalıdır. Cutover öncesinde lag sıfıra yakın olmalıdır.

Data Integrity Kontrolü

Row count, aggregate ve critical business invariant karşılaştırılır. Sample resource ve relationship test edilir. File references doğrulanır. Application integration suite target database üzerinde çalışır. Mismatch varsa cutover ertelenir.

Tenant Directory Güncellemesi

Directory active database location target'a çevrilir. Isolation tier dedicated olarak güncellenir. Routing cache invalidate edilir. Mapping version audit edilir. Source location rollback metadata olarak kısa süre tutulabilir.

Cutover

Gerekirse kısa write freeze uygulanır. Son delta target'a geçirilir. New request'ler dedicated database'e gider. Smoke test customer-facing akışları doğrular. Support ve monitoring ekipleri bilgilendirilir.

Monitoring

Latency, error, connection ve database CPU tenant özelinde izlenir. Source shared shard üzerindeki resource relief ölçülür. Background job ve analytics routing doğrulanır. Alert threshold migration döneminde daha hassas olabilir. Customer SLO karşılaştırılır.

Rollback

Critical error halinde directory source location'a geri çevrilir. Cutover sonrası writes source'a nasıl yansıtılacağı önceden planlanmalıdır. Source data korunur. Rollback karar süresi sınırlı tutulur. Root cause çözülmeden tekrar cutover yapılmaz.

Eski Verinin Silinmesi

Observation ve rollback window tamamlandıktan sonra shared rows temizlenir. Delete chunk'lar halinde yapılabilir. Backup retention ayrı policy'ye tabidir. Cache ve search old records kaldırılır. Deletion verification ve audit tamamlanır.

Open Source ve İşbirliği ile Multi-Tenant Sistemler Geliştirmek

Multi-tenant backend geliştirmek yalnızca framework öğrenmekten ibaret değildir. Açık kaynak veritabanı, ORM, migration ve connection pool araçlarını incelemek gerçek sistem davranışını anlamayı kolaylaştırır. Git ve GitHub üzerinden issue, test ve pull request süreçlerine katılmak code review alışkanlığı kazandırır. Tenant isolation testleri gibi reusable çalışmalar topluluk içinde paylaşılabilir. Açık kaynak proje incelemek farklı SaaS ekiplerinin tenancy, authorization ve migration problemlerini nasıl ele aldığını gözlemleme fırsatı sunar.

PostgreSQL

PostgreSQL kaynakları RLS, transaction ve indexing behavior'ını derinlemesine öğrenmek için değerlidir. Local test environment kurulabilir. Policy ve migration senaryoları küçük projede uygulanabilir. Query plan okumak backend pratiğini geliştirir. Production design öncesinde gerçek veri dağılımıyla benchmark yapılabilir.

Açık Kaynak ORM'ler

ORM source code veya issue tracker global filter ve connection behavior hakkında öğretici bilgiler sunar. Multi-tenancy extension'larının hangi riskleri çözdüğü incelenebilir. Raw SQL ve transaction edge case'leri görülebilir. Test suite tasarımı fikir verebilir. Framework'e kör güvenmek yerine behavior anlaşılır hale gelir.

Migration Araçları

Migration araçları schema version ve rollback yaklaşımını standardize eder. Multi-database orchestrator için reusable building block sağlar. Lock ve transaction behavior tool'a göre değişebilir. Büyük table migration stratejileri test edilmelidir. Tool version upgrade migration pipeline'da ayrıca doğrulanmalıdır.

Connection Pooler'lar

Connection pool behavior tenant context leakage açısından doğrudan önemlidir. Session ve transaction pooling farkı laboratuvar ortamında denenebilir. Connection reset ve failover senaryoları test edilebilir. Metrics integration öğrenilebilir. Bu deneyim production RLS tasarımında önemli avantaj sağlar.

Git ve GitHub

Schema ve security policy değişiklikleri pull request üzerinden review edilebilir. Migration diff ve isolation tests CI'ya bağlanabilir. Issue discussion farklı solution trade-off'larını öğrenmeye yardımcı olur. Public portfolio bu çalışmalar üzerinden oluşturulabilir. Takım içinde knowledge paylaşımı güçlenir.

Tenant Isolation Testleri Paylaşmak

Reusable test fixture veya helper library topluluk projelerinde değerli olabilir. Tenant A ve B test pattern'i farklı framework'lere uyarlanabilir. Property-based isolation suite geliştirilebilir. Security bug fix regression case olarak eklenebilir. Böyle bir proje backend güvenlik bilgisini somutlaştırır.

Open Source SaaS Projelerini İncelemek

Gerçek SaaS repository'leri data model ve authorization kararlarını görmeyi sağlar. Ancak her açık kaynak tasarım production için doğru kabul edilmemelidir. Tenant filter, backup ve migration approach eleştirel incelenmelidir. Issue history neden belirli değişikliklerin yapıldığını gösterebilir. Öğrenilen fikirler küçük demo projede test edilmelidir.

Issue ve Pull Request ile Katkı Sağlamak

İyi bir katkı her zaman büyük feature olmak zorunda değildir. Documentation, test veya bug reproduction önemli başlangıç noktalarıdır. Code review geri bildirimi ekip geliştirme alışkanlığını öğretir. Multi-tenant isolation gibi security-sensitive change dikkatli test gerektirir. Düzenli katkı teknik iletişim becerisini de güçlendirir.

Multi-Tenant SaaS Geliştirmek İçin En İyi Programlama Dili Hangisi?

Multi-tenant SaaS geliştirmek için tek bir en iyi programlama dili bulunmaz. Python, TypeScript, Java, C#, Go ve PHP ile güvenli multi-tenant sistemler kurulabilir. Dil seçimi ekip deneyimi, framework, performans ve operasyon ihtiyaçlarına göre yapılmalıdır. Asıl kritik konu tenant context'in merkezi yönetilmesi, database constraint'lerin doğru kurulması ve isolation testlerinin otomatik olmasıdır. Kötü tenant modeli en iyi framework ile bile güvenli hale gelmez.

Python

Python hızlı backend geliştirme ve güçlü database kütüphaneleri sunar. SQLAlchemy veya Django ORM tenant scoping için kullanılabilir. Async context ve worker tenant state dikkatle yönetilmelidir. PostgreSQL RLS entegrasyonu yapılabilir. Type hints contract clarity sağlar.

TypeScript / JavaScript

Node.js SaaS API geliştirmede yaygın ve üretken bir ekosistem sunar. Async-local context tenant propagation için kullanılabilir fakat leakage test edilmelidir. Prisma veya farklı ORM seçenekleri mevcuttur. TypeScript domain ve API types konusunda yardımcı olur. Runtime authorization yine explicit uygulanmalıdır.

Java

Java enterprise backend ve güçlü transaction yönetimi için uygun olabilir. Hibernate multi-tenancy seçenekleri sunar. Connection pool ve schema switching behavior dikkatle test edilmelidir. Static typing büyük codebase'de domain sınırlarını görünür kılar. Platform automation framework'ten bağımsız tasarlanabilir.

C# / .NET

.NET ve Entity Framework Core global query filter ile tenant scoping sağlayabilir. Dependency injection request tenant context'i taşımaya uygundur. Raw SQL bypass senaryoları test edilmelidir. PostgreSQL veya SQL Server ile farklı RLS seçenekleri kullanılabilir. Background service tenant context'i explicit oluşturmalıdır.

Go

Go sade concurrency modeli ve düşük runtime overhead ile backend service'lerde kullanışlıdır. Context object tenant metadata taşımak için doğal yapı sağlar. SQL query layer tenant filter'ı merkezi helper üzerinden uygulayabilir. Static typing repository interface tasarımını kolaylaştırır. Connection pooling standard library behavior'ı iyi anlaşılmalıdır.

PHP

PHP framework'leri SaaS uygulamalarında hızlı geliştirme sağlar. Global ORM scope tenant filter için kullanılabilir. Queue worker uzun yaşayan process ise tenant state reset özellikle önemlidir. Database RLS ek güvence sağlayabilir. Request lifecycle kısa olsa bile shared cache key tasarımı kritik kalır.

Programlama Dilinden Daha Önemli Olan Veri Modeli ve İzolasyon Tasarımı

Dil değişebilir fakat yanlış tenant ownership modeli uzun yıllar teknik borç olarak kalabilir. Unique constraint, foreign key, RLS ve restore strategy framework'ten bağımsız konulardır. Tenant context tüm katmanlarda güvenilir biçimde taşınmalıdır. Testler isolation invariant'ını kanıtlamalıdır. Bu nedenle backend teknolojisi seçiminden önce veri ve güvenlik sınırı tasarlanmalıdır.

Yazılımcı Olmak İçin Ne Yapmalı? SaaS Backend Yol Haritası

SaaS backend alanında ilerlemek isteyen yazılımcının tek bir framework öğrenmek yerine SQL, transaction, authentication ve distributed systems temellerini birlikte geliştirmesi gerekir. Multi-tenancy bu konuların büyük bölümünü aynı projede buluşturur. PostgreSQL, indexing, queue ve caching bilgisi gerçek SaaS performans sorunlarını anlamayı sağlar. Docker ve cloud deployment operasyon tarafını güçlendirir. En iyi öğrenme yolu küçük fakat gerçek tenant isolation gereksinimleri olan uçtan uca proje geliştirmektir.

Bir Programlama Dilini İyi Öğrenmek

Bir dili yüzeysel biçimde birçok framework ile kullanmak yerine temel runtime ve concurrency behavior'ını anlamak daha değerlidir. Error handling ve testing alışkanlığı geliştirilmelidir. Database driver davranışı öğrenilmelidir. Security input validation dil seviyesinde uygulanabilmelidir. Sonra farklı framework'lere geçiş daha kolay olur.

SQL

Join, aggregation ve transaction gerçek backend işlerinin temelidir. ORM SQL bilgisinin yerine geçmez. Query plan ve index etkisi öğrenilmelidir. Constraint ve foreign key data integrity sağlar. Multi-tenant query'lerde tenant predicate mantığı SQL seviyesinde anlaşılmalıdır.

PostgreSQL

Local PostgreSQL kurulup RLS laboratuvarı yapılabilir. Index ve transaction testleri çalıştırılabilir. Backup ve restore komutları öğrenilebilir. Explain plan okunmalıdır. Small multi-tenant schema gerçek deneyim sağlar.

Transaction ve Isolation Levels

Concurrent update ve race condition backend güvenilirliğini etkiler. Transaction boundary kısa ve anlamlı olmalıdır. Isolation level davranışı testlerle anlaşılabilir. Retry semantics bilinmelidir. Tenant migration sırasında consistency gereksinimleri bu bilgiye dayanır.

Indexing

Composite index ve selectivity öğrenilmelidir. Tenant-first pattern gerçek use case ile test edilebilir. Write cost ve storage etkisi görülmelidir. Explain analyze kullanılabilir. Large tenant dataset üzerinde benchmark yapmak öğreticidir.

Authentication

User identity, session, token ve API key farkları öğrenilmelidir. Secret storage ve password hashing temel security konularıdır. Authentication tenant authorization ile karıştırılmamalıdır. Multi-organization user senaryosu iyi bir çalışma örneğidir. MFA ve SSO sonraki adım olabilir.

Authorization

RBAC ve permission modeli gerçek SaaS ihtiyaçlarını karşılar. Membership ile tenant scope ayrılmalıdır. Resource-level authorization test edilmelidir. IDOR senaryoları öğrenilmelidir. Audit log önemli tamamlayıcıdır.

Multi-Tenancy

Shared schema ile küçük proje başlanabilir. Tenant ID, RLS ve cache prefix uygulanabilir. Cross-tenant leak test yazılmalıdır. Sonra bir tenant dedicated database'e taşınabilir. Bu proje geniş backend bilgisini birleştirir.

Caching

Cache key, TTL ve invalidation öğrenilmelidir. Tenant-aware namespace pratiği yapılmalıdır. Stale data behavior test edilmelidir. Cache hit ve miss metric'leri izlenmelidir. Redis ile küçük laboratuvar kurulabilir.

Queue Sistemleri

Async job, retry ve idempotency gerçek SaaS sistemlerinde sık kullanılır. Tenant context message içinde taşınmalıdır. Worker concurrency ve DLQ öğrenilmelidir. Scheduled job fairness test edilebilir. Event-driven architecture için temel oluşturur.

Docker

Database, cache ve application local environment container ile birlikte çalıştırılabilir. Production'a benzeyen integration test kurulabilir. Migration pipeline containerized job olarak çalıştırılabilir. Network ve secret behavior öğrenilir. CI environment daha tutarlı hale gelir.

Cloud ve Observability

Managed database, metrics, logs ve tracing temel operasyon bilgisidir. Tenant ID telemetry dimension olarak kullanılabilir. Cost monitoring architecture kararlarını etkiler. Backup ve region failure senaryoları test edilmelidir. Infrastructure kullanımını anlamak backend kariyerini güçlendirir.

Gerçek Bir Multi-Tenant SaaS Projesi Geliştirmek

Demo login ekranından daha ileri gidip tenant onboarding, membership, RLS ve export özellikleri eklemek değerlidir. İki tenant fixture ile isolation tests yazılmalıdır. Background job ve cache tenant-aware yapılmalıdır. Backup restore senaryosu dokümante edilmelidir. Proje portföyde architecture kararlarını açıklayan teknik belgeyle sunulabilir.

Diyarbakır Yazılım Topluluğu ile Multi-Tenant SaaS Çalışmaları

Multi-tenant backend ve SaaS mimarisi yalnızca okuyarak değil, birlikte proje geliştirerek çok daha hızlı öğrenilebilir. Diyarbakır Yazılım Topluluğu içinde PostgreSQL, backend, API ve açık kaynak odaklı çalışmalar bu tür konuları gerçek proje bağlamında ele almak için uygun alan oluşturabilir. Topluluğun mevcut proje çalışmalarını görmek için https://www.diyarbakiryazilim.com.tr/projects adresi incelenebilir. Topluluk yapısı ve çalışma alanları hakkında bilgi almak için https://www.diyarbakiryazilim.com.tr/about sayfası kullanılabilir. Multi-tenant veritabanı ve SaaS mimarisi danışmanlığı yakınımda şeklinde araştırma yapan geliştirici veya ekipler için de toplulukla teknik deneyim paylaşımı önemli bir başlangıç olabilir.

Diyarbakır Yazılım Topluluğu İçinde Backend Çalışmaları

Backend çalışma gruplarında authentication, API, database ve testing konuları birlikte ele alınabilir. Katılımcılar shared schema üzerinde küçük SaaS tasarlayabilir. Code review ile tenant isolation hataları tartışılabilir. CI pipeline ve deployment adımları eklenebilir. Öğrenme teoriden production benzeri pratiğe dönüşür.

PostgreSQL ve Database Design Workshopları

Workshop içinde tenants, memberships ve projects tabloları tasarlanabilir. Composite key ve unique constraint örnekleri uygulanabilir. RLS policy gerçek SQL ile test edilebilir. Query plan ve tenant-first index karşılaştırılabilir. Backup ve tenant restore laboratuvarı çalışmanın değerini artırır.

SaaS Architecture Atölyeleri

Katılımcılar shared, schema ve dedicated modeller için karar matrisi oluşturabilir. Farklı müşteri senaryoları gruplara verilebilir. Compliance ve noisy neighbor trade-off'ları tartışılabilir. Hybrid architecture taslağı hazırlanabilir. Sonuç teknik design review formatında sunulabilir.

Row-Level Security Laboratuvarı

PostgreSQL üzerinde iki tenant fixture oluşturulabilir. RLS policy ve runtime role uygulanır. Table owner bypass davranışı gözlemlenir. Connection pooling ile tenant context leakage test edilir. CI için reusable isolation test suite hazırlanabilir.

Open Source ve İşbirliği Projeleri

Topluluk ortak tenant-aware starter template geliştirebilir. Repository, RLS ve cache helpers açık kaynak olarak paylaşılabilir. Issue ve pull request süreçleri katılımcılara gerçek ekip workflow'u öğretir. Security testleri contribution standardının parçası olabilir. Proje dokümantasyonu yeni katılımcılar için öğrenme kaynağı haline gelir.

Diyarbakır'daki En İyi Yazılımcılarla Teknik Deneyim Paylaşımı

Teknik gelişimde en değerli kazanımlardan biri farklı tecrübeye sahip geliştiricilerin aynı problemi farklı açılardan değerlendirmesidir. Database tasarımı, backend güvenliği ve deployment tecrübeleri birlikte konuşulduğunda teori daha somut hale gelir. Code review kültürü bireysel hataları öğrenme fırsatına dönüştürür. Multi-tenancy gibi geniş konular ortak çalışma için özellikle uygundur. Düzenli teknik paylaşım yerel yazılım ekosisteminin üretim kalitesini de yükseltir.

Ortak Proje Fikirleri

Multi-tenant SaaS projeleri backend, frontend, database ve DevOps becerilerini tek çalışmada birleştirir. Küçük ekipler farklı domain'lerde aynı tenancy prensiplerini uygulayabilir. Projelerde onboarding, membership, RLS ve backup senaryoları zorunlu tutulabilir. Cross-tenant leak testleri teknik kabul kriteri olabilir. Üretilen çalışmalar https://www.diyarbakiryazilim.com.tr/projects sayfasındaki proje yaklaşımıyla birlikte değerlendirilebilir.

Multi-Tenant CRM

Her şirket ayrı tenant olarak modellenebilir. Customer, contact ve deal tabloları tenant-scoped olur. Same email farklı tenant'larda bulunabilir. RLS ve tenant-aware search uygulanabilir. Enterprise tenant dedicated database'e taşınarak hybrid model pratiği yapılabilir.

Multi-Tenant Proje Yönetim Sistemi

Organization, workspace ve membership ilişkileri iyi çalışma konusu oluşturur. Project, task ve comment tenant ownership taşır. Same project slug farklı tenant'larda kullanılabilir. Background notification job tenant context ile çalışır. File attachment isolation ayrıca test edilebilir.

Multi-Tenant Randevu Sistemi

Klinik veya işletme tenant olabilir. Appointment ve customer kayıtları tenant-scoped tasarlanır. Time-slot uniqueness tenant bazında korunabilir. Scheduled reminder job tenant context taşır. Data export ve retention özellikleri proje kapsamına eklenebilir.

Multi-Tenant Raporlama Platformu

Tenant dashboard ve platform analytics farkı gerçek use case sağlar. Shared operational data warehouse'a taşınabilir. Customer row-level access uygulanır. Heavy report background queue ile çalışır. Noisy neighbor testleri projenin önemli teknik bölümünü oluşturabilir.

Sık Sorulan Sorular

Çoklu Kiracılı (Multi-Tenant) Veritabanı Tasarım Modelleri hakkında en sık sorulan sorular genellikle hangi storage modelinin seçileceği, RLS'nin yeterli olup olmadığı ve tenant restore sürecinin nasıl çalışacağı etrafında toplanır. Bu soruların tek cümlelik evrensel cevapları yoktur. Tenant sayısı, veri hacmi, müşteri segmenti ve compliance gereksinimleri seçimleri doğrudan etkiler. Aşağıdaki yanıtlar karar verirken kullanabileceğiniz pratik çerçeveyi özetler. Özellikle kurumsal multi-tenant SaaS veritabanı mimarisi geliştirme hizmeti ihtiyacında önce tenant ve isolation gereksinimlerinin ölçülebilir biçimde çıkarılması gerekir.

Multi-tenant veritabanı nedir?

Multi-tenant veritabanı birden fazla müşteri veya organization verisini ortak veya kontrollü biçimde ayrılmış altyapıda tutan modeldir. Her tenant yalnızca kendi verisine erişebilmelidir. Shared schema, separate schema ve dedicated database farklı fiziksel paylaşım seviyeleri sunar. Authentication, authorization, cache ve background job katmanları da tenant-aware olmalıdır. Veritabanı modeli bu uçtan uca isolation yaklaşımının temel parçalarından biridir.

Multi-tenant ile single-tenant arasındaki fark nedir?

Single-tenant modelde müşteri başına ayrı uygulama veya database kaynakları kullanılabilir. Multi-tenant modelde kaynakların daha büyük bölümü paylaşılır. Paylaşım birim maliyeti azaltır fakat logical isolation gereksinimini yükseltir. Dedicated tenant troubleshooting daha kolay olabilir. SaaS ölçeği ve müşteri segmenti hangi yaklaşımın ekonomik olduğunu belirler.

Shared schema nedir?

Tüm tenant'ların aynı database tablolarını paylaştığı modeldir. Satırlar tenant_id ile ayrılır. RLS ve tenant-aware repository güçlü isolation sağlar. Migration tek schema üzerinde çalıştığı için operasyon kolaydır. Tenant-level restore için özel tooling gerekir.

Schema-per-tenant nedir?

Her tenant'ın aynı database içinde ayrı schema kullandığı modeldir. Namespace ayrımı shared schema'dan daha belirgindir. Search path veya explicit schema routing gerekir. Tenant sayısı arttıkça migration fan-out zorlaşır. Orta sayıda B2B tenant için uygun olabilir.

Database-per-tenant nedir?

Her tenant'ın ayrı database kullandığı modeldir. Backup, restore ve region policy tenant bazında uygulanabilir. Isolation güçlüdür. Provisioning ve migration automation zorunludur. Çok sayıda küçük tenant için maliyetli olabilir.

Multi-tenant SaaS için en iyi database modeli hangisidir?

Tek bir en iyi model yoktur. Çok sayıda küçük tenant için shared schema güçlü başlangıçtır. Büyük ve regüle enterprise tenant için dedicated database daha uygun olabilir. Tenant profilleri farklıysa hybrid model güçlü seçenek sunar. Karar restore, compliance, cost ve noisy neighbor gereksinimleriyle birlikte verilmelidir.

tenant_id her tabloda olmalı mı?

Gerçekten global tablolar tenant ID taşımak zorunda değildir. Tenant-scoped tabloların ownership bilgisi açık olmalıdır. Child tabloda tenant ID taşımak composite foreign key ve RLS açısından faydalı olabilir. Her satır için hangi tenant'a ait olduğu güvenilir biçimde belirlenebilmelidir. Data model review bu sınıflandırmayı açıkça yapmalıdır.

PostgreSQL Row-Level Security nedir?

RLS database query sonucunu row seviyesinde policy ile sınırlar. Shared schema tenant isolation için çok değerlidir. Application filter unutulsa bile başka tenant satırlarını engelleyebilir. Runtime role table owner veya BYPASSRLS olmamalıdır. Policy'ler otomatik test edilmelidir.

RLS multi-tenant sistemler için yeterli midir?

RLS önemli bir güvenlik katmanıdır fakat tek başına yeterli değildir. Authentication, membership ve authorization application seviyesinde gerekir. Cache, search ve object storage RLS tarafından korunmaz. Database role yanlışsa policy bypass edilebilir. Defense in depth yaklaşımı daha güvenlidir.

RLS kullanırken application filter gerekli midir?

Çoğu durumda application filter kullanmaya devam etmek faydalıdır. Query intent daha açık olur ve performance açısından tenant predicate görünürdür. RLS hata durumunda ikinci güvenlik katmanı sağlar. İki mekanizma birlikte kullanıldığında developer ergonomisi ve database security birleşir. Integration tests her iki katmanı doğrulamalıdır.

Schema-per-tenant ölçeklenebilir mi?

Doğru automation ile yüzlerce tenant'a ölçeklenebilir. Ancak schema sayısı arttıkça migration ve catalog overhead büyür. Migration orchestrator, version tracking ve canary rollout gereklidir. Binlerce küçük tenant için shared schema daha ekonomik olabilir. Gerçek sınır database ve tooling kapasitesiyle test edilmelidir.

Database-per-tenant pahalı mıdır?

Genellikle shared modele göre daha yüksek operasyon ve altyapı maliyeti taşır. Her tenant için database, connection ve backup yönetimi gerekir. Managed altyapı ve automation bu maliyeti azaltabilir. Büyük enterprise tenant başına gelir modeli karşılayabilir. Hybrid tier fiyatlandırma için uygun bir yaklaşımdır.

Noisy neighbor nedir?

Bir tenant'ın aşırı kaynak kullanımının diğer tenant'ların performansını düşürmesidir. CPU, I/O, connection ve lock contention başlıca kaynaklardır. Tenant bazlı rate limit ve query timeout kullanılabilir. Monitoring diğer tenant p95 ve p99 değerlerini göstermelidir. Büyük tenant dedicated database'e taşınabilir.

Tenant bazında backup nasıl alınır?

Dedicated database modelinde tenant backup doğrudan alınabilir. Schema-per-tenant schema dump kullanılabilir. Shared schema'da full backup ve tenant export yaklaşımı gerekir. Backup encrypted tutulmalıdır. Restore senaryosu backup yönteminden daha kritik test alanıdır.

Shared database'de tek tenant nasıl restore edilir?

Full backup temporary database'e restore edilir. Hedef tenant rows ayrıştırılır. Production'daki yeni data ile conflict resolution yapılır. Tenant rows kontrollü import edilir. File, search ve cache data ayrıca doğrulanır.

Multi-tenant sistem nasıl test edilir?

En az iki tenant fixture oluşturulmalıdır. Read, insert, update ve delete cross-tenant denemeleri yapılmalıdır. Cache, export, search ve background worker test edilmelidir. RLS runtime role ile doğrulanmalıdır. Property-based isolation test coverage'ı genişletebilir.

Bir tenant başka tenant'ın verisini nasıl göremez?

Trusted tenant context authentication ve membership üzerinden belirlenir. Repository tüm query'leri tenant scope ile çalıştırır. PostgreSQL RLS database seviyesinde satır erişimini sınırlar. Cache ve storage tenant-aware namespace kullanır. Cross-tenant leak testleri bu garantiyi sürekli doğrular.

Multi-tenant sistemlerde cache nasıl tasarlanır?

Her tenant-scoped cache key tenant ID içermelidir. Global ve tenant cache namespace'leri ayrılmalıdır. Eviction tenant sınırını aşmamalıdır. Same resource ID collision test edilmelidir. Enterprise tenant gerekirse dedicated cache kullanabilir.

Multi-tenant sistemler nasıl shard edilir?

Tenant ID doğal shard key olabilir. Directory tenant ID ile shard mapping'i tutabilir. Aynı tenant verisi mümkün olduğunca tek shard içinde kalır. Hot shard durumunda tenant rebalancing yapılabilir. Cross-shard analytics ayrı warehouse'a taşınabilir.

Hybrid multi-tenancy nedir?

Aynı SaaS içinde farklı tenant'ların farklı storage isolation modeli kullanmasıdır. Standard tenant shared pool'da olabilir. Enterprise tenant dedicated database kullanabilir. Tenant directory routing'i yönetir. Migration tooling tier değişimini destekler.

Multi-tenant SaaS geliştirmek için en iyi programlama dili hangisidir?

Tek bir en iyi dil yoktur. Python, TypeScript, Java, C#, Go ve PHP ile güçlü SaaS sistemleri geliştirilebilir. Tenant context, database design ve testing dil seçiminden daha önemlidir. Ekip deneyimi ve operations altyapısı tercih üzerinde etkili olmalıdır. PostgreSQL gibi güçlü relational database çoğu dil ile iyi çalışır.

Yazılımcı olmak için database tasarımında neler öğrenilmeli?

SQL, transaction, indexing ve foreign key temel konulardır. Authentication ve authorization database erişimiyle birlikte öğrenilmelidir. Backup, restore ve migration production bilgisi sağlar. Multi-tenancy data ownership düşüncesini geliştirir. Query plan okumak performance becerisini artırır.

Open source ve işbirliği backend kariyerine nasıl katkı sağlar?

Açık kaynak projeler gerçek code review ve test kültürünü görmenizi sağlar. Issue ve pull request teknik iletişim becerisini geliştirir. Database ve ORM internals daha iyi anlaşılır. Küçük security test katkıları bile güçlü öğrenme fırsatıdır. Ortak proje deneyimi profesyonel takım çalışmasına hazırlık sağlar.

Çoklu Kiracılı Veritabanı Tasarımı Hakkında Ek Sorular

Çoklu Kiracılı (Multi-Tenant) Veritabanı Tasarım Modelleri uygulanırken teknik model seçimi kadar güvenlik, yedekleme ve migration süreçlerinin de birlikte düşünülmesi gerekir. Aşağıdaki beş soru bu konudaki en kritik karar noktalarını özetler. Özellikle SaaS uygulamalarında tenant isolation ve row level security nasıl uygulanır sorusunun cevabı yalnızca database policy değil, application ve operasyon katmanlarını da kapsar. Çoklu kiracılı veritabanlarında ölçeklenebilirlik performans ve veri izolasyonu aynı anda ölçülmelidir. Kurumsal multi-tenant SaaS veritabanı mimarisi geliştirme hizmeti veya eğitim ihtiyacında da önce bu gereksinimlerin görünür hale getirilmesi doğru başlangıçtır.

Çoklu kiracılı (Multi-Tenant) veritabanı tasarımı nasıl yapılır?

Önce tenant'ın business anlamı ve veri sahipliği sınırı tanımlanmalıdır. Ardından shared schema, schema-per-tenant veya database-per-tenant modellerinden uygun olanı seçilir. Trusted tenant context authentication ve membership üzerinden oluşturulur. Tenant-aware constraint, index, backup ve monitoring tasarımı aynı modelin parçası olmalıdır. Son olarak cross-tenant leak ve restore testleri production öncesinde otomatik hale getirilmelidir.

Multi-Tenant veritabanlarında shared database, separate schema ve database-per-tenant modelleri arasındaki farklar nelerdir?

Shared database ve shared schema en yüksek kaynak paylaşımını ve en düşük operasyon maliyetini sunar. Separate schema aynı database içinde tenant başına namespace ayrımı sağlar fakat migration fan-out maliyeti getirir. Database-per-tenant güçlü isolation, backup ve restore kolaylığı sunarken provisioning ve connection management daha zordur. Tenant sayısı, veri hacmi ve compliance gereksinimi seçim üzerinde doğrudan etkilidir. Birden fazla müşteri segmenti varsa hybrid model bu yaklaşımları aynı üründe birlikte kullanabilir.

Çoklu kiracılı veritabanlarında tenant verilerinin izolasyonu ve güvenliği nasıl sağlanır?

Tenant context client request'inden doğrudan alınmamalı, authenticated identity ve membership üzerinden doğrulanmalıdır. Repository query'leri tenant scope ile çalışmalı ve PostgreSQL gibi sistemlerde RLS ikinci savunma katmanı olarak kullanılmalıdır. Composite foreign key ve tenant-aware unique constraint veri integrity'yi güçlendirir. Cache, search, file storage ve worker katmanları da aynı tenant ID namespace'ini korumalıdır. Cross-tenant read, write, export ve file erişim testleri CI pipeline'da düzenli çalıştırılmalıdır.

Multi-Tenant veritabanı mimarisinde performans, ölçeklenebilirlik, yedekleme ve veri taşıma süreçleri nasıl yönetilir?

Tenant-first indexing ve query timeout shared database performansının temel araçlarındandır. Noisy neighbor riskini azaltmak için rate limit, workload queue ve büyük tenant promotion yaklaşımı kullanılabilir. Backup politikası tenancy modeline göre tasarlanmalı ve özellikle tek tenant restore senaryosu düzenli test edilmelidir. Sharding tenant ID veya directory mapping ile yapılabilir. Shared pool'dan dedicated database'e data taşıma için historical copy, incremental sync, verification, cutover ve rollback adımları otomatik workflow haline getirilmelidir.

Çoklu kiracılı veritabanı tasarımı ve SaaS mimarisi konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Diyarbakır'da backend, SaaS mimarisi, veritabanı tasarımı ve açık kaynak konularında üretim yapmak isteyen geliştiriciler Diyarbakır Yazılım Topluluğu'nun çalışmalarını inceleyebilir. Topluluk hakkında bilgi için https://www.diyarbakiryazilim.com.tr/about adresi kullanılabilir. Proje odaklı çalışmalar için https://www.diyarbakiryazilim.com.tr/projects sayfası incelenebilir. Multi-tenant veritabanı ve SaaS mimarisi danışmanlığı yakınımda şeklinde araştırma yapan ekipler için de doğru başlangıç mevcut tenant, güvenlik, backup ve migration gereksinimlerini birlikte değerlendirmektir. Böyle bir teknik değerlendirme shared schema'dan dedicated database'e kadar hangi isolation seviyesinin gerçekten gerekli olduğunu daha net ortaya çıkarır.

Sonuç: Doğru Multi-Tenant Veritabanı Mimarisi Nasıl Kurulur?

Doğru Çoklu Kiracılı (Multi-Tenant) Veritabanı Tasarım Modelleri seçimi yalnızca bugün kaç müşteriniz olduğuna göre yapılmamalıdır. Tenant isolation, restore süresi, noisy neighbor riski, compliance ve future migration ihtiyaçları birlikte değerlendirilmelidir. Shared schema birçok SaaS için son derece verimli başlangıç olabilir, ancak tenant context merkezi yönetilmeli ve database seviyesinde ek savunma uygulanmalıdır. Büyük veya regüle müşteriler için hybrid isolation yolunu açık tutmak ileride mimariyi tamamen değiştirme ihtiyacını azaltır. Multi-tenant SaaS tasarımı, database kararından çok authentication, cache, jobs, storage, analytics ve observability dahil tüm sistemin tenant sınırına göre davranmasını gerektirir.

Önce Tenant ve İzolasyon Gereksinimini Tanımlayın

Tenant'ın kim olduğunu açıkça belirlemeden database modeli seçilmemelidir. Organization ve workspace arasındaki data ownership farkı anlaşılmalıdır. Hangi verinin kim tarafından görülebileceği yazılı hale getirilmelidir. Compliance ve restore ihtiyacı listelenmelidir. Teknik tasarım bu gereksinimlerin sonucu olmalıdır.

Gereksiz Fiziksel İzolasyonla Başlamayın

Her tenant için database açmak güvenli görünse de operasyon maliyeti yüksek olabilir. Çok sayıda küçük tenant için shared schema güçlü başlangıçtır. RLS ve tenant-aware constraints güvenliği destekler. Enterprise requirement geldiğinde promotion path kullanılabilir. Maliyet ile gerçek risk dengelenmelidir.

Shared Schema Kullanıyorsanız Tenant Context'i Merkezi Hale Getirin

Tenant resolution her endpoint'te tekrar yazılmamalıdır. Middleware authentication ve membership kontrolü yapmalıdır. Trusted context repository ve worker katmanına taşınmalıdır. Request body tenant ID'sine güvenilmemelidir. Bu merkezileştirme developer hatasını önemli ölçüde azaltır.

Database Seviyesinde Defense in Depth Uygulayın

Application filter tek savunma olmamalıdır. PostgreSQL RLS ve tenant-aware constraints ek güvence sağlar. Runtime database role minimum yetkili olmalıdır. RLS bypass ve table owner davranışı test edilmelidir. Security isolation CI pipeline'ın sürekli kontrolü haline gelmelidir.

İndeks, Constraint ve Foreign Key'leri Tenant-Aware Tasarlayın

Composite unique constraint tenant business semantics'ini korur. Composite foreign key cross-tenant ilişkiyi engelleyebilir. Tenant-first index common query pattern'leri hızlandırır. Global unique ve global key kararları açık gerekçeye dayanmalıdır. Data model tenant boundary'yi fiziksel olarak görünür hale getirmelidir.

Backup'tan Önce Tenant Restore Senaryosunu Tasarlayın

Backup job'un çalışması tek tenant restore garantisi değildir. Temporary database, extraction ve merge runbook hazırlanmalıdır. RPO ve RTO ölçülebilir hedef olmalıdır. Dedicated tenant için independent restore avantajı değerlendirilebilir. DR testleri gerçek data büyüklüğüyle düzenli yapılmalıdır.

Noisy Neighbor ve Cross-Tenant Leak Testlerini Otomatikleştirin

Güvenlik ve performance release sonrası kullanıcı şikayetiyle ölçülmemelidir. Cross-tenant read ve write testleri CI'da çalışmalıdır. Heavy tenant workload küçük tenant SLO'larıyla karşılaştırılmalıdır. Rate limit ve query timeout mekanizmaları test edilmelidir. Büyük tenant promotion threshold telemetry'ye dayanmalıdır.

Tenant Provisioning ve Migration İşlerini Baştan Otomatikleştirin

Schema veya database oluşturma manual kaldığında büyüme hızla operasyon yüküne dönüşür. Provisioning state machine resource, migration ve health adımlarını yönetmelidir. Database-per-tenant migration orchestrator version drift'i kontrol etmelidir. Retry ve rollback tasarıma dahil edilmelidir. Automation ekiplerin customer sayısı arttıkça aynı hizmet kalitesini korumasını sağlar.

Büyük veya Regüle Tenant'lar İçin Hibrit İzolasyon Yolunu Açık Tutun

Her tenant'ın aynı storage modelinde kalması zorunlu değildir. Standard müşteri shared pool içinde çalışabilir. Enterprise veya regulated tenant dedicated database ve region kullanabilir. Tenant directory dynamic routing sağlamalıdır. Bu yaklaşım isolation'ı maliyetli global varsayılan yerine ihtiyaca göre ürün özelliğine dönüştürür.

Multi-Tenancy'yi Yalnızca Veritabanı Kararı Değil Uçtan Uca Sistem Sınırı Olarak Tasarlayın

Tenant isolation database'de başlayıp cache, search, storage, queue, analytics ve audit katmanlarında devam eder. Bir katmanda tenant context kaybolduğunda güçlü database tasarımı tek başına yeterli olmaz. Bu nedenle tenancy standartları tüm servis ve ekipler tarafından ortak biçimde uygulanmalıdır. Çoklu kiracılı SaaS altyapısı, veriyi paylaşmanın değil güvenli sınırlar içinde paylaşabilmenin mühendisliğidir. Kendi projenizde bu modeli kurmak, ekip içinde uygulamalı çalışma yapmak veya kurumsal multi-tenant SaaS veritabanı mimarisi geliştirme hizmeti konusunda bilgi almak için https://www.diyarbakiryazilim.com.tr üzerinden Diyarbakır Yazılım Topluluğu'na ulaşabilirsiniz.