Corex360
Mühendislik14 Mayıs 20268 dk okuma

Binlerce işletme, tek çekirdek: çok kiracılı mimariyi ölçeklemek

Veri izolasyonu, tek çekirdeğin binlerce kiracıya hizmet vermesi, olay tabanlı gerçek zamanlı senkronizasyon ve kiracı bazında KVKK uyumu — üretim gözüyle.

Yazan Şevket Erer

Çok kiracılı (multi-tenant) bir SaaS, dışarıdan tek bir uygulama gibi görünür; içeride ise binlerce işletmenin verisini aynı çekirdeğin üzerinde, birbirine asla değdirmeden taşıyan bir disiplindir. Corex360'ın her ay düzenlediği mühendislik webinarının da değişmez konusu budur: tek bir kod tabanı, tek bir altyapı, ama her kiracı için kendi dünyası gibi hissettiren bir sistem nasıl kurulur.

İzolasyon: şema mı, satır mı?

İlk ve en kritik karar veri izolasyonudur. İki ana yaklaşım vardır: her kiracıya ayrı bir şema (schema-per-tenant) ya da paylaşılan tablolarda her satırı bir tenant_id ile etiketleme (row-level). Şema bazlı yaklaşım güçlü fiziksel ayrım ve kolay yedekleme verir ama on binlerce şemayı yönetmek migration'ları ağırlaştırır. Satır bazlı yaklaşım operasyonel olarak hafiftir, ölçeklenir; ancak tek bir eksik WHERE koşulu felakettir. Pratikte hibrit kazanır: çoğu modül için satır bazlı izolasyon + veritabanı seviyesinde zorunlu kılınan satır güvenlik politikaları (RLS), büyük kurumsal kiracılar için ise mantıksal ayrım.

Önemli olan, izolasyonu uygulama koduna güvenerek değil, mümkün olan en alt katmanda zorunlu kılmaktır. tenant_id filtresini her sorguya elle eklemeyi unutan bir geliştirici, bir gün başka bir kiracının verisini sızdırır. Bu yüzden filtre veritabanı politikasına ve ortak sorgu katmanına gömülür; geliştirici onu atlamak istese bile atlayamaz.

Çok kiracılı mimaride güvenlik bir özellik değil, varsayılan davranıştır; istisna değil, kuraldır.

Tek çekirdek, gerçek zamanlı senkron

Corex360'ta WhatsApp'tan düşen bir mesajın aynı anda gelen kutusunda, CRM kartında ve BI panosunda belirmesi gerekir. Bunu her ekranı sürekli sorgulatarak değil, olay tabanlı (event-driven) bir omurgayla çözeriz: bir şey olduğunda — yeni mesaj, kesilen fatura, hareket eden araç — sistem bir olay yayınlar, ilgili modüller onu dinler ve kendini günceller. Tek çekirdek binlerce kiracıya hizmet verirken bile, her kiracının olayları yalnızca kendi sınırları içinde dolaşır.

Bu mimari, modülleri birbirinden gevşek bağlı tutar. Araç takip modülü stok modülünün iç yapısını bilmek zorunda değildir; ikisi de aynı olay diline konuşur. Yeni bir modül eklemek, çekirdeği yeniden yazmak değil, akışa yeni bir dinleyici katmaktır. Ölçeklenmenin sırrı, büyüklüğü değil, bağımsızlığı yönetmektir.

Kiracı bazında yetki ve KVKK/GDPR

Türkiye'de KVKK, Avrupa'da GDPR — her ikisi de 'verinin kime ait olduğu ve kimin görebileceği' sorusuna net cevap ister. Çok kiracılı bir sistemde bu, iki katmanlı bir yetkilendirme demektir: önce kiracı sınırı (bir işletmenin kullanıcısı asla başka bir işletmenin verisine erişemez), sonra kiracı içi roller (saha şefi araç verisini görür, muhasebeci faturayı, herkes her şeyi değil).

Uyumun pratik yüzü, denetlenebilirliktir: hangi veriye kim, ne zaman erişti; bir kiracı verisinin silinmesi istendiğinde gerçekten ve yalnızca o kiracının izinin silinmesi; veri saklama sürelerinin kiracı bazında uygulanabilmesi. İyi bir multi-tenant mimari, KVKK'yı sonradan yapıştırılan bir uyum katmanı olarak değil, izolasyon kararının doğal bir sonucu olarak taşır.

İlgili yazılar

Sertifikalar & Uyumluluk
ISO 27001Bilgi Güvenliği
ISO 9001Kalite Yönetimi
SOC 2 Type IIUyumluluk
KVKKVeri Koruma