SaaS Ürününde Çok Kiracılı Mimari Kararı

Tenant, ürünün ayrı müşteri alanını temsil eder; çoğu projede bu bir şirkettir. Ancak bir şirketin birden fazla bağımsız çalışma alanı olabilir. Kullanıcı, şirket, çalışma alanı ve abonelik ilişkisini ilk veri modelinde açıklayın.

Örneğimizde bir kullanıcı iki kuruma üye olabilir; aktif kurum seçimi üyelik üzerinden doğrulanır. Kullanıcının tarayıcıdan gönderdiği kurum kimliğine tek başına güvenilmez. Kurum değiştirildiğinde eski ekran verisi, arama sonuçları ve indirme bağlantılarının yeni bağlama taşınmaması da kabul kapsamına girer.

Kaynak paylaşımı ile izolasyon aynı karar değildir. Paylaşılan bir altyapıda erişim sınırları kurulabilir; ayrı veritabanı kullanan bir üründe de uygulama yanlış veritabanına bağlanırsa veri sınırı ihlal edilebilir. Her modelde kimlik, yönlendirme ve erişim kontrolleri gereklidir.

Tenant kimliği yalnızca ana veri tablosunda bulunursa dosyalar, arama indeksleri veya önbellek üzerinden yanlış veri dönebilir. İlgili kaynağın sahibini doğrulayan kontrol dosya indirme, rapor, arama ve dışa aktarma işlemlerinde de uygulanmalıdır.

Arka plan görevleri kullanıcı isteğinden sonra çalışır. Bu işler tenant bağlamını açıkça taşımalı ve çalıştırma sırasında doğrulamalıdır. Destek personelinin kurum verisine erişimi de ayrı yetki, süre ve kayıtla sınırlandırılabilir. Yetkili bir destek rolünün bulunması sınırsız görünürlük anlamına gelmemelidir.

Toplam sunucu kullanımı normal görünürken tek bir müşteri ağır raporlarla diğerlerini bekletebilir. İstek, kuyruk ve veri hacmini tenant düzeyinde gözlemleyebilecek ölçüm planı hazırlayın. Hangi sınırların ürün paketinden, hangilerinin teknik kapasiteden geldiğini açıklayın.

Temsili ürünümüzde toplu dışa aktarma ayrı kuyruğa alınır ve aynı kurumun eşzamanlı rapor sayısı sınırlanır. Bu evrensel bir sayı veya hazır performans garantisi değildir. Gerçek limitler yük testi, iş ihtiyacı ve kullanıcı deneyimiyle belirlenmelidir. Sınır aşıldığında kullanıcıya bekleme veya yeniden deneme davranışı anlaşılır biçimde gösterilir.

Tüm veritabanının yedeğinin bulunması, tek bir müşterinin verisini güvenle geri yükleyebileceğiniz anlamına gelmez. Geri yükleme sırasında diğer müşterilerin güncel kayıtlarını koruma yöntemi, bağlantılı dosyalar ve arama indeksleriyle birlikte test edilmelidir.

Tenant açma, dondurma, dışa aktarma ve kapatma işlemleri bir yaşam döngüsüdür. Kurum kapandığında kullanıcı üyelikleri, kuyruktaki işler ve entegrasyon anahtarları nasıl ele alınacak? Saklama ve silme kararları işin gerçek koşullarıyla netleşmeli; teknik süreç bu kararlara göre uygulanmalıdır.

Karar belgesi yalnızca seçilen teknolojiyi değil, hangi koşullarda seçildiğini anlatmalıdır. Beklenen müşteri sayısı, veri büyüklüğü, ekibin işletim becerisi ve müşteri bazlı geri yükleme ihtiyacı başlangıç girdileridir. Bilinmeyenleri gerçekmiş gibi doldurmak yerine açık soru olarak bırakın.

A ve B kurumları için ayrı kayıt, dosya ve kullanıcılar oluşturun. A kullanıcısının B kaydını doğrudan kimlikle istemesi, B dosyasını indirmesi ve arama üzerinden görmesi reddedilmelidir. Normal arayüzün bu bağlantıları göstermemesi yeterli değildir.

Ayrıca kurum değişimi sonrası önbellek, rolün kaldırılması, gecikmiş arka plan işi ve toplu dışa aktarma senaryolarını sınayın. Bir tenant’ın yükü artırıldığında diğerinin yanıt süresini gözlemleyin. Sonuçları test kaydı ve sorumlu ile ilişkilendirin; yalnızca modelin adına dayanarak güvenlik veya ölçek garantisi vermeyin.

Müşteri portalı yetkileri · MVP kapsamı · Proje brief oluşturucu