B2B SaaS’ta En Zor Karar
B2C uygulamalarını geliştirdiğinizde veriler basittir: her kullanıcının kendi verisi vardır. Ancak bir B2B SaaS platformu (örneğin, farklı şirketler için bir envanter sistemi) geliştirdiğinizde, Multi-Tenancy’nin karmaşık dünyasına adım atarsınız.
Şirket A ve Şirket B aynı uygulamayı kullanıyor. SaaS’ta en kötü senaryo, Şirket A’nın yanlışlıkla Şirket B’nin finansal verilerine erişmesidir. Bu veri sızıntısını önlemek, alacağınız en kritik mimari karardır ve iki temel veri tabanı stratejisinden birini seçmek zorundasınız.
Strateji 1: Paylaşımlı Veri Tabanı (Global Scopes)
En yaygın yaklaşım, tüm kullanıcıları aynı veritabanına koymak ve her bir tabloya bir tenant_id sütunu eklemektir.
Laravel’de, bunu Global Scopes kullanarak zorunlu hale getirirsiniz. Bir geliştirici invoices tablosunu sorguladığında, Laravel otomatik olarak arka planda WHERE tenant_id = 1 ekler.
// Inside an Eloquent Model
protected static function booted()
{
static::addGlobalScope('tenant', function (Builder $builder) {
$builder->where('tenant_id', session('current_tenant_id'));
});
}
Artıları: Hosting açısından son derece ucuzdur ve migration işlemlerini yürütmek oldukça kolaydır. Sadece bir veritabanını yönetmeniz yeterlidir.
Eksileri: Son derece risklidir. Eğer bir geliştirici yanlışlıkla raw SQL sorgusu yazarsa ve tenant_id‘yı unutursa veya karmaşık bir arka planda iş sırasında bir global scope düşerse, veri şirketler arasında sızar.
Strateji 2: Veri Tabanı İzolasyonu (Ayrı DB’ler)
Kurumsal B2B platformları için sıkı Veri Tabanı İzolasyonu tercih ediyoruz. Şirket A’nın database_a, Şirket B’nin ise database_b vardır.
Laravel için Tenancy gibi paketler kullanarak, uygulama, kullanıcının girişi veya alt alan adına (örneğin, companya.smarttechdevs.in) göre dinamik olarak veri tabanı bağlantısını değiştirir.
Artıları: Toplam veri güvenliği. Şirket A’nın Şirket B’nin verilerine sorgu atması matematiksel olarak imkansızdır çünkü fiziksel olarak ayrılmışlardır. Ayrıca, tek bir müşterinin verisini yedeklemek veya silmek son derece kolaydır.
Eksileri: DevOps karmaşıklığı. Yeni bir özellik yayımladığınızda, php artisan migrate komutunu bir kez çalıştırmakla yetinmezsiniz. 50 farklı müşteri veritabanı için döngüyle çalıştırmanız gerekir.
Hüküm
Düşük maliyetli ve yüksek hacimli bir SaaS geliştiriyorsanız, Strict Global Scopes ve yoğun otomatik testlerle Paylaşımlı Veri Tabanını tercih edin. Ancak, veri gizliliğinin hukuksal olarak zorunlu olduğu kurumsal B2B yazılımı geliştiriyorsanız, DevOps karmaşıklığına katlanmak zorundasınız ve sıkı Veri Tabanı İzolasyonu mimarisi geliştirmelisiniz.
Kaynak: Orijinal Makale
