Tek müşteriden çoğula geçiş sanıldığından zor
PlusTurk'ü ilk kurduğumda tek bir hukuk bürosu için yazılmış basit bir araçtı. Birden fazla firma kullanmak isteyince "zaten çalışıyor, biraz uyarlarım" diye düşündüm. Yanıldım. Çok kiracılı (multi-tenant) bir mimariye geçmek, kod yazmaktan çok varsayımları yeniden kurmak demek. Gördüğüm ve kendi yaptığım en sık hataları paylaşıyorum.
Hata 1: Tenant ID'yi sonradan eklemek
Tabloları tek kiracı varsayımıyla tasarlayıp sonradan tenantId sütunu eklemek, mevcut bütün sorguları tek tek gözden geçirmeniz gerektiği anlamına gelir. Bir tane unutursanız, bir firmanın verisi başka bir firmaya sızabilir. Doğrusu: en baştan her tabloya tenantId eklemek, hatta mümkünse veritabanı seviyesinde satır bazlı güvenlik (row-level security) kullanmak.
model CaseFile {
id String @id @default(cuid())
tenantId String // en baştan zorunlu alan
// ...
@@index([tenantId])
}Hata 2: Her sorguda tenant filtresini elle yazmaya güvenmek
Elle her findMany çağrısına where: { tenantId } eklemek, bir noktada mutlaka unutulur. Bunun yerine, veri erişim katmanını (repository/service) tek bir yerden geçirip tenant filtresini orada zorunlu kılmak çok daha güvenli.
Hata 3: Paylaşılan kaynakları (SMS, ödeme) yanlış izole etmek
PlusTurk'te her firma kendi SMS ve sanal POS hesabını bağlıyor. Bunu paylaşılan tek bir hesap üzerinden yapsaydık, bir firmanın gönderdiği SMS'in faturası başka bir firmaya çıkabilir ya da bir firmanın ödeme sorunu diğerini etkileyebilirdi. Kiracılar arası kaynak izolasyonu, veri izolasyonu kadar önemli.
Hata 4: Ölçeklenmeyi düşünmeden rapor sorguları yazmak
Tek kiracılı bir sistemde "tüm kayıtları say" sorgusu sorun değildir. Yüzlerce kiracı olduğunda aynı sorgu veritabanını kilitleyebilir. Rapor ve dashboard sorgularını en baştan indekslenmiş, kiracı bazlı çalışacak şekilde tasarlamak gerekiyor.
// Riskli: tüm tabloyu tarar
const total = await prisma.caseFile.count();
// Doğru: index kullanan, kiracıya özel sorgu
const total = await prisma.caseFile.count({ where: { tenantId } });Hata 5: Özelleştirmeyi kod dallanmasıyla çözmek
Bir müşteri "bende şu farklı olsun" dediğinde kod içine if (tenantId === "xyz") yazmak cazip gelir. Bu, kısa vadede hızlı ama uzun vadede bakımı imkansız bir kod yığınına dönüşür. Doğrusu: özelleştirmeleri veritabanında tutulan konfigürasyon/ayar olarak modellemek — tıpkı bu sitenin admin panelindeki Site Ayarları gibi, kodu değil veriyi değiştirerek davranışı özelleştirmek.
Sonuç
Multi-tenant mimari, "aynı kodu birden fazla müşteriye satmak" değil; izolasyon, güvenlik ve ölçeklenebilirliği en baştan tasarıma gömmek demek. PlusTurk'teki en büyük öğrenim şu oldu: bu kararları sonradan düzeltmek, en baştan doğru kurmaktan çok daha pahalıya mal oluyor.