Çok Kiracılı (Multi-Tenant) CRM Mimarisi: "Verileriniz Ayrı Tutulur" Cümlesi Nerede Biter?

Çok kiracılı mimari, tek bir yazılım kurulumunun birden fazla müşteriye — kiracıya — aynı anda hizmet vermesidir. Alternatifi tek kiracılıdır: her müşteri için ayrı bir kurulum, ayrı bir sürüm, ayrı bir bakım hattı. Çok kiracılı olmak bir kusur değil, bulut yazılımının maliyet ve güncelleme modelidir; yeni bir sürüm tek seferde bütün kiracılara ulaşır.

Ayrımın nasıl kurulduğu ise sabit değil. Üç yaklaşım tarif edilir ve üçü de "verileriniz ayrı tutulur" cümlesiyle anlatılabilir.

1. Paylaşılan tablo, kiracı sütunu

Bütün müşterilerin kayıtları aynı tablolarda durur; her satırda bir kiracı kimliği sütunu vardır ve ayrım tamamen uygulama kodunun o sütunu doğru filtrelemesine bağlıdır. En ucuz ve en esnek olan budur. Ayrımı koruyan tek şey koddur: filtreyi unutan tek bir sorgu sınırın karşı tarafını görür ve bunu veritabanı tarafında durduran bir kural yoktur.

2. Ortak veritabanı sunucusu, kiracı başına ayrı veritabanı

Her müşterinin kendi veritabanı ve kendi tablo dosyaları vardır; hepsi aynı veritabanı sunucusu üzerinde çalışır. Ayrım artık uygulama filtresine değil, bağlantının hangi veritabanına açıldığına bağlıdır. Uygulamada unutulan bir kiracı filtresi bu kurguda karşı tarafın kayıtlarını getirmez, çünkü o kayıtlar bağlantının veritabanında bulunmaz. Sınır burada da mutlak değildir: sunucu, işletim sistemi ve veritabanı kullanıcısı ortaktır.

3. Kiracı başına ayrı kurulum

Ayrı sunucu, ayrı veritabanı sunucusu, ayrı ağ. Ayrımın en katı hâli budur ve maliyeti de en yüksek olan budur; her müşteri ayrı bir işletim yükü demektir. Bir sağlayıcı bunu yapıyorsa o maliyet bir yerde fiyata yansır.

Bir sağlayıcı hangisini kastettiğini söylemiyorsa, cümle üçüne de uyar.

Bu fark alıcı için nerede ortaya çıkar?

Günlük kullanımda üç model de aynı görünür: aynı ekranlar, aynı hız, aynı adres. Fark üç anda görünür.

Birincisi olay anında. Bir arıza, bir kaynak tükenmesi ya da bir bakım penceresi kaç müşteriyi aynı anda etkiler? Ayrım ne kadar aşağı katmanda kurulmuşsa etki alanı o kadar dar olur.

İkincisi ayrılırken. Sözleşme bittiğinde verinizin çıkarılması ve silinmesi, ayrı bir veritabanında tek bir işlem; paylaşılan bir tabloda ise satır satır bir ayıklama işi. Sağlayıcının size ne kadar hızlı ve ne kadar eksiksiz cevap verebileceğini büyük ölçüde bu belirler.

Üçüncüsü denetim sırasında. Bir müşteriniz ya da denetçiniz "verimiz kimin verisiyle aynı yerde duruyor" diye sorduğunda vereceğiniz cevap, sağlayıcınızın mimarisinden daha ileri gidemez. Bu yüzden cevabın kapsamını sözleşme aşamasında öğrenmek, olaydan sonra öğrenmekten ucuzdur.

1. Ayrı veritabanı, ayrı sunucu demek değil

Kiracı veritabanlarının hepsi (23 Eylül 2026'da 25) aynı MySQL örneği üzerinde çalışıyor ve uygulama hepsine tek bir veritabanı hesabıyla bağlanıyor. Kiracıya özel bir sunucu, kiracıya özel bir donanım ya da kiracıya özel bir veritabanı parolası yok. Pratik anlamı şu: ayrım veritabanı düzeyinde gerçek, ama veritabanı sunucusunun kendisi ortak bir kaynak. Sunucuyu etkileyen bir olay — yük, kaynak tükenmesi, bakım penceresi — bütün kiracıları aynı anda etkiler. Bunu "ayrı sunucu" diye yazamayız, yazmıyoruz da.

2. İşletim günlükleri paylaşılan bir tabloda duruyor

CRM kayıtlarınız ayrı bir veritabanında. Uygulamanın kendi hata kayıtları öyle değil. Ana veritabanındaki tek bir hata günlüğü tablosunda ölçtüğümüz değerler: 39.842 satır, 26 farklı kiracı, 26.357 kullanıcı e-posta adresi, 26.908 IP adresi ve 13.597 istek gövdesi — hepsi aynı paylaşılan tabloda.

Buradaki 26 sayısı, bugün sistemde bulunan 24 kiracıdan fazla. Sebebi rahatsız edici ölçüde basit: ayrılmış müşterilerin satırları hâlâ orada. Ayrılan kiracının CRM veritabanına ne olduğunu ölçmedik ve silindiğini yazmıyoruz; ölçtüğümüz tek şey, günlük satırlarının silinmemiş olduğu.

Bu neden önemli: bir hata günlüğü satırı yalnızca bir hata mesajı değildir. İçinde kimin, hangi adresten, hangi isteği yaptığı durur; bu kişisel veridir. "Verileriniz ayrı tutulur" cümlesi o satırları kapsamaz. Bizim cümlemiz de kapsamadığını söylüyor — CRM verileriniz derken kastedilen dar kapsam tam olarak budur. Bu yazıdaki hukuki nitelendirmeler ve sözleşmeye ilişkin öneriler bilgilendirmedir, hukuki görüş değildir; kendi yükümlülüğünüzü kendi hukuk danışmanınızla değerlendirin.

3. Diskte şifreleme yok

Veritabanının tamamı üzerinde ölçtük: 23 Eylül 2026'da Rapitek CRM'in 6.412 veritabanı tablosunun hiçbiri veritabanı düzeyinde şifreli değildi ve diskte bir disk şifreleme katmanı yok. Yani veriniz ayrı bir veritabanında duruyor, ama düz metin olarak duruyor. Uygulama düzeyinde şifrelenen dar bir grup var; başlıcaları: e-posta hesabı OAuth jetonları; WhatsApp Business, Instagram ve Meta erişim jetonları ile webhook sırları; ödeme ve İYS sağlayıcı kimlik bilgileri; iki adımlı doğrulama sırları ve yedek kodları; ses izleri — bunlar veritabanına yazılmadan önce Fernet ile şifreleniyor. Parolalar ise geri çözülemeyen özet olarak saklanır. Bunun dışında "verileriniz şifreli saklanır" cümlesini yazamayız ve yazmıyoruz.

Bu sayıları neden yazıyoruz?

Üçü de aleyhimize. Yine de yazıyoruz, çünkü bu üç sınırı yazmayan bir sağlayıcının "verileriniz ayrı tutulur" cümlesi ile bizimki okur açısından ayırt edilemez hale gelir. Ayırt edilebilir olmasının tek yolu, cümlenin nerede bittiğini de söylemek.

Bunların bir kısmı kapatılabilir sınırlar: işletim günlüklerinin kiracı başına ayrılması ya da eski kayıtların silinmesi bir mühendislik işidir ve yapılabilir. Bir kısmı ise mimari tercihtir — kiracı başına ayrı sunucu, bugünkü fiyat ve işletim modelimizle uyuşmuyor. Hangisinin hangisi olduğunu şimdiden söylemek, sonradan "zaten öyleydi" demekten daha dürüst.