SaaS14 dk okuma

SaaS Ürün Geliştirmede Multi-Tenancy Stratejileri

SaaS uygulamalarında multi-tenant mimari nasıl kurulur?

A

Architecture Team

Solution Architects

5 Ocak 2025

Multi-Tenancy Nedir?

Multi-tenancy, tek bir uygulama instance'ının birden fazla müşteri (tenant) tarafından kullanılmasını sağlayan mimari yaklaşımdır. SaaS uygulamalarının temel taşıdır ve doğru implementation ile büyük maliyet tasarrufu sağlar.

Multi-Tenancy Modelleri

1. Shared Database, Shared Schema

Tüm tenant'lar aynı database ve tabloları kullanır. TenantId ile ayrım yapılır.

-- Örnek tablo yapısı
CREATE TABLE users (
  id UUID PRIMARY KEY,
  tenant_id UUID NOT NULL,
  email VARCHAR(255),
  name VARCHAR(255),
  INDEX idx_tenant (tenant_id)
);

-- Query örneği
SELECT * FROM users WHERE tenant_id = ? AND email = ?;

2. Shared Database, Separate Schema

Her tenant için ayrı schema oluşturulur.

-- Tenant A için
CREATE SCHEMA tenant_a;
CREATE TABLE tenant_a.users (...);

-- Tenant B için
CREATE SCHEMA tenant_b;
CREATE TABLE tenant_b.users (...);

3. Separate Database

Her tenant için tamamen ayrı database kullanılır.

Isolation Levels Karşılaştırması

SeviyeGüvenlikPerformansMaliyet
Shared EverythingDüşükYüksekDüşük
Row-Level SecurityOrtaOrtaDüşük
Schema IsolationYüksekOrtaOrta
Database IsolationÇok YüksekDüşükYüksek

Implementation Best Practices

Tenant Resolution

// Subdomain based
app.use((req, res, next) => {
  const subdomain = req.hostname.split('.')[0];
  req.tenantId = getTenantBySubdomain(subdomain);
  next();
});

// Header based
app.use((req, res, next) => {
  req.tenantId = req.headers['x-tenant-id'];
  next();
});

// JWT token based
app.use((req, res, next) => {
  const token = verifyJWT(req.headers.authorization);
  req.tenantId = token.tenantId;
  next();
});

Database Sharding Stratejileri

  • Horizontal Sharding: Tenant'ları farklı database server'lara dağıtma
  • Vertical Sharding: Farklı feature'ları farklı database'lere ayırma
  • Geographic Sharding: Coğrafi lokasyona göre dağıtım (GDPR compliance)
  • Size-based Sharding: Tenant büyüklüğüne göre resource allocation

Güvenlik Önlemleri

🔒 Kritik Güvenlik Noktaları:

  1. Data Isolation: Tenant verilerinin kesinlikle birbirine karışmaması
  2. Access Control: Tenant-specific RBAC implementasyonu
  3. Encryption: Tenant bazında encryption key'leri
  4. Audit Logging: Tüm tenant aktivitelerinin loglanması
  5. Rate Limiting: Tenant bazında API limit kontrolü

Performance Optimization

// Connection pooling per tenant
class TenantConnectionPool {
  private pools = new Map<string, Pool>();
  
  getConnection(tenantId: string): Pool {
    if (!this.pools.has(tenantId)) {
      this.pools.set(tenantId, createPool({
        host: this.getTenantHost(tenantId),
        database: this.getTenantDatabase(tenantId),
        max: 20,
        idleTimeoutMillis: 30000
      }));
    }
    return this.pools.get(tenantId);
  }
}

Tenant Onboarding Otomasyonu

Yeni tenant onboarding süreci:

  1. Tenant kaydı oluştur ve unique identifier ata
  2. Database/Schema provision et
  3. Default data seed et (roller, yetkiler, ayarlar)
  4. Subdomain/Custom domain ayarla
  5. SSL sertifikası oluştur
  6. Welcome email gönder ve onboarding flow başlat

Monitoring ve Analytics

  • Tenant bazında resource kullanımı (CPU, memory, storage)
  • API call patterns ve rate limiting
  • Database query performance per tenant
  • Feature usage analytics
  • Cost allocation ve billing metrics

Common Pitfalls

⚠️ Dikkat Edilmesi Gerekenler:

  • Tenant context'i global variable'da tutmak (thread safety issues)
  • Cross-tenant data leakage (yetersiz validation)
  • Shared cache without tenant isolation
  • Insufficient testing for tenant isolation
  • Missing tenant context in background jobs
SaaSArchitectureCloudMulti-tenancyDatabaseSecurity
Paylaş:

Projeleriniz İçin Destek Alın

Uzman ekibimizle projelerinizi hayata geçirin

WhatsApp'tan İletişime Geç