B.001■ SIGNAL LOG ■--:--
← SIGNAL LOG
#0012025-05-01

Çok Kiracılı SaaS Mimarisi: Bunu Yaparken Öğrendiklerim

SaaSArchitectureBackend

Sıfırdan çok kiracılı bir SaaS inşa etmek, hiçbir tutorial'ın anlatmadığı şeyleri öğretiyor. İşte kullandığım zihinsel model.

Çok kiracılı bir SaaS geliştirmek, sonradan geri alması acı verecek kararları erkenden almanızı zorluyor. Bunu iki kez yaptım — bir kez yanlış, bir kez doğru. İşte gerçekten önemli olanlar.

İlk seferinde yaptığım en büyük hata, kiracı verilerini veritabanı düzeyinde izole etmek yerine uygulama katmanında birbirine karıştırmaktı. PostgreSQL'deki satır düzeyi güvenlik (RLS) hak ettiği ilgiyi görmüyor. Veri izolasyonunu her sorguda hatırlamanız gereken bir şey olmaktan çıkarıp bir veritabanı garantisine dönüştürüyor.

Kiracı başına şema yaklaşımı temiz görünüyor — ta ki 500 kiracınız olup migration çalıştırmanız gerekene kadar. Paylaşımlı şema ve tenant_id ise doğru indeksleme ve satır düzeyi güvenlik eklenene kadar karmaşık kalıyor. Seçiminizi estetik kaygılara göre değil, izolasyon gereksinimlerinize göre yapın.

Kimlik doğrulama için token'a kiracı bağlamını yerleştirdiğim bir JWT yapısı kullanıyorum. Her API çağrısı tenant ID'yi taşıyor, her sorgu otomatik olarak kapsama alınıyor. Yanlışlıkla veri sızıntısı olmuyor.

En zor kısım mimari değil — kenar durumlar. Kiracı onboarding'i (veritabanı oluşturma, varsayılan değerleri yerleştirme, subdomain kurma), offboarding (veriyi dışa aktarma, foreign key sırasına göre kayıt silme) ve askıya alma (silme değil, işaretleme).

Baştan başlasaydım: paylaşımlı şema + satır düzeyi güvenlik, PostgreSQL ve net bir kiracı bağlamı middleware'i ile başlardım. Kiracı başına şemaya ancak tek bir kiracının veri hacmi bunu gerektirdiğinde geçerdim.

POST #001YY.DEV