
Multi-tenant bir SaaS çözümü inşa etmek yalnızca teknik bir tasarım meselesi değil; aynı zamanda organizasyonel hedeflerle uyumlu, sürdürülebilir ve ölçeklenebilir bir yapının oluşturulmasıdır. Bu yapıyı anlamak için yalnızca uygulama bileşenlerine değil, aynı zamanda onu çevreleyen yönetim ve operasyonel servislere de yakından bakmak gerekir. İşte bu noktada, multi-tenant architecture fundamentals devreye girer.
Bu yazıda, çok kiracılı (multi-tenant) SaaS mimarilerinin yapı taşlarını, mimari düzeydeki iki temel düzlemi (control plane ve application plane), tenant izolasyonu, onboarding süreci, veri bölümlendirmesi (data partitioning) gibi kavramları bütünsel bir bakışla ele alacağız.
1. SaaS Mimarilerinin İki Yüzü: Control Plane ve Application Plane
Her SaaS mimarisi aslında iki ana bölümden oluşur:
- Control Plane:
Sistemin yönetim katmanıdır. Tenant onboarding, identity management, metering, billing, metrics ve admin dashboard gibi bileşenleri içerir. İlginç şekilde bu katmandaki servislerin kendileri multi-tenant olmak zorunda değildir, çünkü sistemin “yönetimini” üstlenirler. - Application Plane:
Bu katmanda uygulamanın business logic’i ve işlevsellikleri yer alır. Burada tenant context devreye girer ve sistemin her tenant için nasıl davranması gerektiği belirlenir. Tenant isolation, data routing, user roles ve deployment modelleri bu düzlemde tasarlanır.
Bu iki düzlem birlikte çalışarak hem kullanıcı deneyimini optimize eder hem de operasyonel verimliliği artırır.
2. Tenant Isolation: İzolasyon Seviyeleri ve Stratejileri
Multi-tenant sistemlerde tenant isolation hayati önem taşır. Amaç; her tenant’ın verisinin ve deneyiminin diğerlerinden tamamen izole olmasını sağlamak, bunu yaparken de operasyonel ve maliyet verimliliğinden ödün vermemektir.
İzolasyon stratejileri genellikle şu şekildedir:
- Compute Isolation: Her tenant’a özel compute kaynakları (örneğin, ayrı container veya pod).
- Data Isolation: Her tenant’ın kendi veritabanı, tablo veya şemaya sahip olması.
- Network Isolation: Tenant’ların birbirine ağ seviyesinde erişememesi.
- Logical Isolation: Tekil bir altyapı üzerinde yazılımsal kontrollerle tenant’ların ayrıştırılması.
İdeal sistemlerde bu seviyeler ihtiyaca göre hibrit şekilde uygulanır.
3. Data Partitioning ve Tenant Routing
Multi-tenant bir sistemde verilerin nasıl bölümlendiği (data partitioning) ve her tenant’ın taleplerinin doğru veriyle nasıl eşleştirildiği (tenant routing) belirleyicidir.
- Data partitioning, performans, güvenlik ve ölçeklenebilirlik açısından optimize edilmelidir. Tipik stratejiler arasında:
- Shared Schema, Tenant ID Column
- Separate Schemas per Tenant
- Separate Databases per Tenant
- Hybrid Models
- Tenant routing mekanizması, kullanıcıdan gelen request’in hangi tenant’a ait olduğunu tanımlayarak doğru compute ve storage kaynaklarına yönlendirilmesini sağlar. Bu, authentication token içerisindeki tenant ID gibi verilerle yapılabilir.
4. Tenant Onboarding: Süreç Otomasyonu
Tenant onboarding süreci SaaS sistemlerde genellikle şu adımlardan oluşur:
- Tenant kimliğinin oluşturulması (Tenant ID)
- Identity provider entegrasyonu (SSO, OAuth, vs.)
- Gerekli veri yapılarının oluşturulması
- Faturalandırma ve izleme sistemlerinin entegre edilmesi
- Tenant admin kullanıcılarının atanması
Bu adımların her biri, control plane üzerinden otomatikleştirilerek hızlı ve hatasız bir onboarding deneyimi sağlanmalıdır.
5. Deployment Modelleri: Paylaşım Seviyeleri
SaaS çözümleri için farklı deployment modelleri mevcuttur ve her biri farklı seviyede izolasyon ve kaynak paylaşımı sunar:
- Full Stack Silo: Her tenant için tüm altyapı ve uygulama yığını ayrıdır.
- Full Stack Pool: Uygulama ve altyapı tamamen paylaşılır, tenant ayrımı yazılımsal yapılır.
- Pod Deployment: Tenant’lar belirli gruplara ayrılarak kaynaklar bölüştürülür.
- Hybrid Model: Sistem içinde bazı servisler shared bazıları dedicated olabilir.
Bu modeller arasında seçim yaparken maliyet, domain ihtiyaçları ve regülasyonlar dikkate alınmalıdır.
Sonuç:
Multi-tenant SaaS mimarileri; teknoloji, iş stratejisi ve operasyonel süreçlerin hassas dengelerle birleştiği yapılardır. Her ne kadar shared infrastructure ve unified deployment gibi kavramlar cazip görünse de her SaaS çözümü kendi domain’ine, regülasyonlara ve büyüme stratejisine göre özelleştirilmiş bir mimariyi hak eder.
Mimari kararlar yalnızca bugünü değil, gelecekteki scale, agility ve operasyonel verimlilik ihtiyacını da adreslemelidir. SaaS geliştiricileri için bu temel ilkeleri bilmek, sadece yazılımı değil, aynı zamanda sürdürülebilir bir iş modelini de inşa etmek anlamına gelir.