Çok Kiracılı SaaS Oluşturma: Çalışma Alanları, Roller, Faturalandırma ve İzolasyon

Çok kiracılı SaaS, bir avuç müşterinin ötesine geçmeyi bekleyen herhangi bir B2B platformu için varsayılan mimaridir. Ancak detaylarda şeytan gizlidir: çalışma alanlarını nasıl modellendiğiniz, roller atadığınız, faturalamayı yapılandırdığınız ve kiracıları izole ettiğiniz, platformunuzun sorunsuz ölçeklenip ölçeklenmeyeceğini veya karmaşıklık altında çöküp çökmeyeceğini belirler. DigiForge'da bu sistemleri düzinelerce SaaS ürününde kurduk ve yeniden inşa ettik. İşte öğrendiklerimiz.

Çalışma Alanları: Organizasyonun Temel Birimi

Çalışma alanı, tek bir müşteri (veya müşteri içindeki bir ekip) için kullanıcıları, verileri ve yapılandırmayı gruplayan mantıksal bir kapsayıcıdır. Ekiplerin çalışma alanlarını fatura hesaplarıyla ve hatta projelerle karıştırdığını gördük—bunu yapmayın. Çalışma alanını temel kiracı kapsamı olarak tutun ve diğer kavramları bunun üzerine katmanlayın.

Anahtar tasarım kararları:

• Hiyerarşik mi yoksa düz mü? Bazı platformlar, çalışma alanları içinde çalışma alanlarına ihtiyaç duyar (örneğin, birden çok departmanı olan bir kuruluş). İki seviyeli bir hiyerarşi öneriyoruz: organizasyon (fatura varlığı) ve çalışma alanı (ekip birimi). Kesinlikle gerekli olmadıkça daha derin iç içe geçmekten kaçının—rol devralmayı ve veri erişimini karmaşıklaştırır.
• Benzersiz tanımlayıcılar: URL'lerde çalışma alanı için insan tarafından okunabilir bir kısa ad (örneğin acme veya acme-marketing) kullanın, ancak dahili olarak her zaman bir UUID'ye güvenin. Kısa adlar değişebilir; UUID'ler değişmemelidir.
• Bekleme süreli yumuşak silme: Bir çalışma alanını silmek sert bir eylemdir. Kullanıcıların verileri kurtarabilmesi için 30 günlük bir yumuşak silme uygulayın. Faturalamayı hemen durdurun ancak bekleme süresi dolana kadar verileri saklayın.

Yeni bir kullanıcı kaydolduğunda, onboarding akışını düşünün. Önce bir çalışma alanı mı oluşturmalı, yoksa bir sandbox'ı keşfedebilmeli mi? Biz, kullanıcının önce bir organizasyon, ardından ilk çalışma alanını oluşturduğu ve hemen ekip arkadaşlarını davet etmesi için yönlendirildiği rehberli bir akışı tercih ediyoruz. Bu, sürtünmeyi azaltır ve platformun işbirlikçi olduğu beklentisini oluşturur.

Yaygın bir hata, faturalandırma planlarını doğrudan çalışma alanlarına bağlamaktır. Bunun yerine, faturalandırmayı bir veya daha fazla çalışma alanı içeren bir organizasyona bağlayın. Bu, kurumsal müşterilerin tek bir fatura almasını sağlarken her ekibin kendi çalışma alanına sahip olmasına olanak tanır.

Roller ve İzinler: İnce Ayar, Ama Çok İnce Değil

Rol tabanlı erişim kontrolü (RBAC) endüstri standardıdır, ancak ayrıntı düzeyi önemlidir. DigiForge'da genellikle üç yerleşik rolle başlarız—Admin, Üye, İzleyici—ve gelişmiş planlar için özel rollere izin veririz. Admin rolü tam çalışma alanı kontrolüne sahiptir, Üyeler çoğu kaynağı oluşturup düzenleyebilir ve İzleyiciler yalnızca okuyabilir.

İşlerin karmaşıklaştığı nokta izin kapsamıdır. İzinler varsayılan olarak çalışma alanına göre kapsamlandırılmalıdır, ancak organizasyon düzeyinde izinlere (örneğin, faturalandırmayı yönetme) veya konsolide raporlama için çalışma alanları arası okuma erişimine ihtiyacınız olabilir. İzinleri bir dizi action:resource çifti olarak modelleyin ve rollere atayın. Atamaları bir birleşim tablosunda saklayın: (workspace_id, user_id, role_id).

Bize iyi hizmet eden bir desen, kullanıcının rolünü her istekte veritabanını sorgulamak yerine bir oturum belirteci (JWT) içinde önbelleğe almaktır. Ancak dikkatli olun: rolleri JWT'lerde önbelleğe alırsanız, bir rol değiştiğinde belirteçleri geçersiz kılmak için bir mekanizmanız olmalıdır (örneğin, kısa belirteç süre sonu veya bir kara liste).

Ayrıca rol kalıtımını da düşünün: bir organizasyon Yöneticisi otomatik olarak tüm çalışma alanlarında Yönetici olmalı mı? Bizim kuralımız: organizasyon rolleri bir tavan sağlar, ancak çalışma alanı rolleri daha kısıtlayıcı olabilir. Örneğin, bir Organizasyon Yöneticisi herhangi bir çalışma alanına erişebilir, ancak bir çalışma alanı Yöneticisi faturalamaya erişemez.

Faturalama ve Fiyatlandırma Modelleri: Meta-Veri, İş Mantığı Değil

Faturalama, çok kiracılılığın gerçek olduğu yerdir. Fiyatlandırma modeliniz (koltuk başına, çalışma alanı başına, kullanım tabanlı veya katmanlı) veri modelinize yansıtılmalıdır, ancak faturalama sisteminiz çekirdek uygulamanızdan ayrıştırılmalıdır. Üçüncü taraf bir faturalama sağlayıcısı (Stripe, Recurly, Chargebee) kullanın ve veritabanınızda yalnızca abonelik kimliği ve plan kimliğini saklayın.

Aşağıdaki veritabanı yaklaşımını öneriyoruz:

1. Plan slug'ını, fiyatını ve özellik bayraklarını (ör. max_users, storage_gb, api_rate_limit) tanımlayan bir plans tablosu.
2. current_plan_id ve billing_provider_subscription_id alanlarına sahip bir organizations tablosu. Organizasyonları çalışma alanlarına bir birleştirme tablosu aracılığıyla bağlayın.
3. Geçersiz kılmaları depolayan bir features tablosu (veya basit bir JSON sütunu). Örneğin, bir müşteri özel bir oran müzakere ederse, planın fiyatını organizasyon düzeyinde geçersiz kılın.

En zor kısım, plana göre erişimi sınırlamaktır. İki seçeneğiniz var: sınırlamaları uygulamada zorlamak (davet etmeden önce max_users'ı kontrol etmek) veya veritabanı satır sayıları ve tetikleyiciler aracılığıyla zorlamak. Biz uygulama düzeyinde zorlamayı tercih ediyoruz çünkü daha iyi kullanıcı dostu hata mesajları üretiyor, ancak her zaman sınırları aşan organizasyonları işaretleyen bir gece mutabakat işi ekliyoruz.

Plan yükseltmeleri ve düşürmeleri dikkatli bir şekilde ele alınmalıdır. Bir müşteri yükseltme yaptığında, yeni özelliklere hemen erişim izni verin ancak faturalandırmayı sağlayıcınız aracılığıyla orantılı olarak hesaplayın. Düşürme durumunda, karar vermeniz gerekir: yeni planı aşan özelliklere erişimi engellemek mi yoksa bir ödeme süresi tanımak mı? Mevcut fatura dönemi boyunca bir ödeme süresi öneriyoruz, ardından kısıtlamaları uyguluyoruz.

Saha deneyiminden bir ders: fatura başarısızlıklarının asla veri kaybına yol açmasına izin vermeyin. Bir ödeme başarısız olursa, nazikçe düşürün (ör. yazma işlemlerini kısıtlayın) ancak verileri silmeyin. Müşteriniz sonunda ödeyecektir.

Kiracı İzolasyonu: Paylaşımlı ve Silo

İzolasyon, en önemli mimari karardır. Standart ödünleşim, paylaşımlı bir veritabanı (tüm kiracılar için tek bir veritabanı, her tabloda tenant_id sütunu) ile kiracı başına veritabanı (her çalışma alanı kendi veritabanını alır) arasındadır. İkisini de denedik ve çoğu proje için hibrit bir yaklaşımda karar kıldık.

• Sıkı RLS ile paylaşımlı: Küçük ve orta ölçekli kiracılar (her biri 10 bin kullanıcının altında) için iyidir. Satır düzeyinde güvenlik Postgres'e yerleşiktir ve her sorguyu filtrelemek için bir oturum değişkeni (app.tenant_id) kullanırız. Bu, işletmesi ve yükseltmesi en kolay olanıdır.
• Kiracı başına veritabanı: Kiracılar sıkı uyumluluk (HIPAA, SOC 2, GDPR veri yerleşimi) gerektirdiğinde veya uygulama kiracı başına yoğun G/Ç yaptığında gereklidir. Operasyonel yük gerçektir—şema geçişleri yüzlerce veritabanına uygulanmalıdır—ancak Flyway gibi araçlar ve otomatik CI bunu yönetilebilir kılar.
• Kiracı başına şema: Tek bir veritabanı içinde ayrı şemalar kullanan bir orta yol. Paylaşımlı tablodan daha fazla izolasyon sunar, ancak tam veritabanlarından daha az operasyonel yük getirir. Bunu alt seviye planlarımız için kullanırız ve ihtiyaç duyarlarsa müşterileri kiracı başına veritabanına yükseltiriz.

İzolasyon stratejisi ne olursa olsun, istemciden doğrudan veritabanı erişimine asla izin vermeyin. Her zaman kiracı kimliğini zorunlu kılan bir API katmanı üzerinden yönlendirin. Ve nöbetçi ekibinizin hatrına: URL'lerde tenant_id kullanıyorsanız, kimliği doğrulanmış kullanıcının o kiracıya ait olduğunu doğrulamadan asla kullanmayın.

İzolasyon seviyeleri arasında veri taşıma bir gerçektir. Örneğin, bir kiracı paylaşımlı veritabanını aştığında, onu özel bir veritabanına taşımanız gerekebilir. Bunu erken planlayın: verileri dışa ve içe aktaran bir geçiş betiği yazın ve üretim benzeri verilerle test edin. Mavi-yeşil yaklaşım kullanarak kesintisiz çalıştırılabilmelidir.

Otomatik Sağlama: İşi Makineye Bırakın

Yeni kiracıları manuel olarak başlatmak ilk on müşteri için işe yarayabilir, ancak ölçeklenemez. ContractorHUB'ın yakın tarihli patent başvurusunun vurguladığı gibi, sıfır dokunuşlu uygulama, çok kiracılı SaaS için önemli bir farklılaştırıcıdır [1]. Veritabanı oluşturmadan (veya şema klonlamadan) varsayılan verileri doldurmaya ve karşılama e-postaları göndermeye kadar her şeyi otomatikleştiren sağlama iş akışları oluşturduk.

Tipik bir otomatik sağlama hattı:

1. Kullanıcı kaydolur, bir organizasyon oluşturur ve bir plan seçer.
2. Fatura sağlayıcınızdan gelen bir webhook, bir sağlama işini tetikler (örneğin, sunucusuz bir işlev veya bir Kubernetes Job).
3. İş, kiracının izolasyon katmanını (şema veya veritabanı) oluşturur, ilk geçişleri çalıştırır ve varsayılan rolleri ve ayarları doldurur.
4. İkinci bir iş, giriş talimatları ve sonraki adımları içeren bir e-posta gönderir.
5. Kullanıcı, saniyeler içinde tamamen işlevsel olan yeni çalışma alanına yönlendirilir.

Burada idempotentlik tartışılmaz bir gerekliliktir. Sağlama işi yarı yolda başarısız olursa, yeniden denemek güvenli olmalıdır. Tüm süreci, organizasyon satırında bir provisioning_status sütunu olan bir durum makinesine sarıyoruz: pending → creating → active → failed. Başarısız durumlar, insan müdahalesi için bir ölü mektup kuyruğuna gönderilir.

Destek altyapısını sağlamayı unutmayın: özel alan adları için DNS kayıtları, CDN önbellek ısıtıcıları, kiracı başına API hız sınırları ve izleme uyarıları. Komut dosyasıyla yazılabilen her şeyi otomatikleştirin, çünkü manuel adımlar baskı altında unutulacaktır.

Sonuç: Çok Kiracılı Zihniyet

Çok kiracılılık, lansmandan sonra eklenen bir özellik değildir. Veri modelinize, erişim kontrolünüze, faturalandırma entegrasyonunuza ve dağıtım stratejinize ilk günden itibaren yön vermelidir. İyi haber: bu dört temel direği—çalışma alanları, roller, faturalandırma, izolasyon—doğru kurarsanız, SaaS'ınızın geri kalanını oluşturmak ve sürdürmek dikkat çekici derecede kolaylaşır.

Her SaaS farklıdır, ancak yukarıdaki kalıplar endüstriler arasında bize iyi hizmet etti. İster MVP'nize yeni başlıyor olun, ister binlerce kiracıya ölçekleniyor olun, bu kararlar üzerinde derinlemesine düşünmenizi öneririz. Ve mimariniz için ikinci bir çift göz isterseniz, her zaman incelemekten mutluluk duyarız.