Çok Kiracılı SaaS Desenleri: İzolasyon, Ölçek ve Yapay Zeka Tasarımı

Çok kiracılık ne demektir (Jargondan uzak)\n\nÇok kiracılık, tek bir çalışan sistemin aynı yazılım ürünü üzerinden birden çok müşteriye (kiracıya) hizmet vermesi demektir. Her kiracı “kendi uygulamasına” sahipmiş gibi hisseder, ama perde arkasında altyapının bazı parçalarını—aynı web sunucuları, aynı kod tabanı ve sıklıkla aynı veritabanı—paylaşırlar.\n\nYararlı bir zihinsel model apartman binasıdır. Herkesin kendi kilitli birimi (verileri ve ayarları) vardır, ama binanın asansörü, tesisat ve bakım ekibini paylaşırsınız (uygulamanın hesaplama, depolama ve operasyonları).\n\n### Takımlar neden çok kiracılıyı seçer\n\nÇoğu takım çok kiracılı SaaS'i mod olduğu için seçmez—verimli olduğu için seçerler:\n\n- paylaşılan altyapı, genellikle müşteri başına tam bir stack açmaktan daha ucuzdur.\n- izlenecek, yamalanacak ve korunacak tek bir platform (yüzlerce küçük dağıtım yerine).\n- iyileştirmeler herkes için aynı anda gider ve müşteriler arasında “sürüm sapması” engellenir.\n\n### Nerede ters gidebilir\n\nİki klasik başarısızlık modu vardır: ve .\n\nGüvenlik açısından: kiracı sınırları her yerde uygulanmazsa, bir hata müşteriler arası veri sızıntısına neden olabilir. Bu sızıntılar nadiren dramatik “hack”lerdir—çoğunlukla eksik bir filtre, yanlış yapılandırılmış izin kontrolü veya kiracı bağlamı olmadan çalışan bir arka plan işi gibi sıradan hatalardır.\n\nPerformans açısından: paylaşılan kaynaklar, bir yoğun kiracının diğerlerini yavaşlatabileceği anlamına gelir. O “gürültülü komşu” etkisi, yavaş sorgular, patlayan iş yükleri veya tek bir müşterinin orantısız API kapasitesi tüketmesi olarak görünebilir.\n\n### Bu yazıda ele alınacak desenlere kısa bakış\n\nBu makale ekiplerin bu riskleri yönetmek için kullandığı yapı taşlarını inceliyor: veri izolasyonu (veritabanı, şema veya satır), kiracı farkındalıklı kimlik ve izinler, gürültülü-komşu kontrolleri ve ölçeklendirme ile değişiklik yönetimi için operasyonel desenler.\n\n## Temel Takas: İzolasyon vs Verimlilik\n\nÇok kiracılık, nerede duracağınızla ilgili bir tercihtir: kiracılar arasında ne kadar paylaşacaksınız ya da her kiracıya ne kadar ayıracaksınız. Aşağıdaki her mimari desen bu çizgide farklı bir noktadır.\n\n### Paylaşılan vs adanmış kaynaklar: temel spektrum\n\nBir uçta kiracılar neredeyse her şeyi paylaşır: aynı uygulama örnekleri, aynı veritabanları, aynı kuyruklar, aynı cache'ler—tenant ID'leri ve erişim kurallarıyla mantıksal olarak ayrılmıştır. Bu genellikle kapasiteyi havuzladığınız için en ucuz ve en kolay işletilebilir olandır.\n\nDiğer uçta ise kiracılara sistemin kendi “dilimi” verilir: ayrı veritabanları, ayrı hesaplama kaynakları, bazen ayrı dağıtımlar. Bu güvenlik ve kontrolü artırır, ancak operasyonel yük ve maliyetleri yükseltir.\n\n### Neden izolasyon ve maliyet zıt yönlere çeker\n\nİzolasyon, bir kiracının diğerinin verilerine erişme, performans payını tüketme veya alışılmadık kullanım kalıplarından etkilenme ihtimalini azaltır. Ayrıca belirli denetimler ve uyumluluk gereksinimlerini karşılamayı kolaylaştırır.\n\nVerimlilik ise boş kapasiteyi birçok kiracı arasında paylaştırdığınızda iyileşir. Paylaşılan altyapı daha az sunucu çalıştırmanıza, daha basit dağıtım boru hatlarına sahip olmanıza ve ölçeği en kötü durum yerine toplam talebe göre yapmanıza olanak tanır.\n\n### Karar vericiler (common decision drivers)\n\nDoğru noktanız nadiren felsefidir—çoğunlukla kısıtlar tarafından yönlendirilir:\n\n- sıkı çalışma süresi veya gecikme hedefleri daha fazla izolasyona iter.\n- gereksinimler adanmış depolama veya adanmış ortamlar gerektirebilir.\n- erken ürünler genellikle daha hızlı ilerlemek için daha paylaşılan başlar; sonra büyük müşteriler için adanmış seçenekler sunabilirsiniz.\n- daha fazla izolasyon genellikle izlenecek, yamalanacak ve taşınacak daha çok şey demektir.\n\n### Desen seçimi için basit bir zihinsel model\n\nKendinize iki soru sorun:\n\n1) \n\n2) \n\nEğer patlama yarıçapı çok küçük olmalıysa, daha adanmış bileşenler seçin. Maliyet ve hız en önemliyse, daha fazla paylaşın—ve paylaşımı güvenli tutmak için güçlü erişim kontrolleri, oran limitleri ve kiracı bazlı izleme yatırımı yapın.\n\n## Hızlı Bakış: Çok Kiracılı Modeller\n\nÇok kiracılık tek bir mimari değildir—müşteriler arasında altyapıyı paylaşmanın (veya paylaşmamanın) bir dizi yoludur. En iyi model ihtiyaç duyduğunuz izolasyon miktarına, beklenen kiracı sayısına ve ekibinizin taşıyabileceği operasyonel yük miktarına bağlıdır.\n\n### 1) Tek kiracı (adanmış) — temel\n\nHer müşteri kendi uygulama yığınına (veya en azından kendi izole çalışma zamanı ve veritabanına) sahip olur. Güvenlik ve performans açısından en kolay akla yatkın olan budur, ancak genellikle kiracı başına en pahalıdır ve operasyonların ölçeklenmesini yavaşlatabilir.\n\n### 2) Paylaşılan uygulama + paylaşılan veritabanı — en düşük maliyet, en fazla dikkat gerektirir\n\nTüm kiracılar aynı uygulama ve veritabanında çalışır. Maliyetler genellikle en düşüktür çünkü yeniden kullanımı maksimize edersiniz, ama kiracı bağlamına (sorgular, önbellekleme, arka plan işleri, analiz dışa aktarımları) her yerde titizlikle dikkat etmelisiniz. Tek bir hata çapraz-tenant veri sızıntısına dönüşebilir.\n\n### 3) Paylaşılan uygulama + ayrı veritabanı — daha güçlü izolasyon, daha fazla operasyon\n\nUygulama paylaşılıyor, ancak her kiracının kendi veritabanı (veya veritabanı örneği) vardır. Bu, olaylardaki patlama yarıçapı kontrolünü iyileştirir, tenant seviyesinde yedekleme/geri yüklemeyi kolaylaştırır ve uyumluluk konuşmalarını basitleştirebilir. Dezavantaj operasyoneldir: daha çok veritabanı sağlamak, izlemek, taşıma ve güvenlik gerektirir.\n\n### 4) Büyük müşteriler için hibrit modeller\n\nBirçok SaaS ürünü yaklaşımları karıştırır: çoğu müşteri paylaşılan altyapıda yaşarken, büyük veya düzenlemeye tabi müşteriler adanmış veritabanı veya adanmış compute alır. Hibrit genellikle pratik son durumdur, ama kim hak kazanır, maliyeti ne olur ve güncellemeler nasıl uygulanır gibi net kurallar olmalıdır.\n\nDaha derin izolasyon teknikleri istiyorsanız, /blog/data-isolation-patterns metnini referans olarak tutun.\n\n## Veri İzolasyon Desenleri (DB, Şema, Satır)\n\nVeri izolasyonu basit bir soruyu yanıtlar: “Bir müşteri başka bir müşterinin verisini görüp etkileyebilir mi?” Üç yaygın desen vardır ve her birinin farklı güvenlik ve operasyonel sonuçları vardır.\n\n### Satır düzeyinde izolasyon (paylaşılan tablolar + )\n\nTüm kiracılar aynı tabloları paylaşır ve her satırda sütunu bulunur. Bu, küçükten orta ölçekli kiracılar için altyapıyı minimize ettiği ve raporlama/analitiği basit tuttuğu için en verimli modeldir.\n\nRisk de basittir: herhangi bir sorgu ile filtrelemeyi unutursa veri sızdırabilirsiniz. Tek bir “admin” uç noktası veya arka plan işi zayıf nokta olabilir. Azaltma yöntemleri şunlardır:\n\n- Geliştiricilerin filtreleri elle yazmamasını sağlamak için paylaşılan bir veri erişim katmanında tenant filtrelemesini zorlamak\n- Mümkünse row-level security (RLS) gibi veritabanı özelliklerini kullanmak\n- Kasıtlı olarak çapraz-tenant erişimi deneyen otomatik testler eklemek\n- Tenant kapsamlı sorguların hızlı kalması için yaygın erişim yollarında indeksleme yapmak (genellikle veya )\n\n### Şema-başına-kiracı (aynı veritabanı, ayrı şemalar)\n\nHer kiracı kendi şemasına (ör. , ) sahip olur. Bu, satır düzeyine göre izolasyonu artırır ve tenant ihracı veya tenant-özel ayarlama yapmayı kolaylaştırabilir.\n\nDezavantaj operasyoneldir. Migration'lar birçok şema üzerinde çalıştırılmalı ve hatalar daha karmaşık hale gelir: 9.900 kiracı başarıyla migrate olurken 100 tanesinde takılabilirsiniz. İzleme ve araçlar burada önemlidir—migration sürecinizin net retry ve raporlama davranışı olmalı.\n\n### Veritabanı-başına-kiracı (ayrı veritabanları)\n\nHer kiracıya ayrı bir veritabanı verilir. İzolasyon güçlüdür: erişim sınırları daha net, bir kiracının gürültülü sorguları diğerini daha az etkiler ve tek bir kiracıyı yedekten geri yüklemek daha temizdir.\n\nMaliyet ve ölçeklendirme temel dezavantajlardır: yönetilecek daha fazla veritabanı, daha fazla connection pool ve potansiyel olarak daha fazla yükseltme/migration işi. Birçok ekip bu modeli yüksek değerli veya düzenlemeye tabi kiracılar için ayırır, küçük kiracılar paylaşılan altyapıda kalır.\n\n### Kiracı büyüdükçe shard ve yerleştirme stratejileri\n\nGerçek sistemler genellikle bu desenleri karıştırır. Yaygın bir yol, erken büyüme için satır düzeyi izolasyonu kullanmak ve ardından daha büyük kiracıları ayrı şemalara veya veritabanlarına “mezun etmek”tir.\n\nSharding, hangi veritabanı kümesinde bir kiracının yaşacağını (bölge, boyut katmanı veya hashing ile) kararlaştıran bir yerleştirme katmanı ekler. Anahtar, kiracı yerleşimini açık ve değiştirilebilir yapmak—böylece kiracıyı taşımak için uygulamayı yeniden yazmak zorunda kalmazsınız ve yeni shard ekleyerek ölçeklenirsiniz.\n\n## Kimlik, Erişim ve Kiracı Bağlamı\n\nÇok kiracılık şaşırtıcı derecede sıradan şekillerde başarısız olur: eksik bir filtre, kiracılar arası paylaşılan bir önbelleğe alınmış nesne veya isteğin kim için olduğunu “unutmuş” bir admin özelliği. Çözüm tek bir büyük güvenlik özelliği değil—isteğin ilk baytından son veritabanı sorgusuna kadar tutarlı bir kiracı bağlamıdır.\n\n### Kiracı tanımlama ("kimin olduğu" nasıl anlaşılır)\n\nÇoğu SaaS ürünü birincil bir tanımlayıcı üzerinde karar kılar ve diğerlerini kolaylık olarak kabul eder:\n\n- kullanıcılar için kolaydır ve kiracı markalı deneyimlerle iyi çalışır.\n- API istemcileri ve dahili servisler için kullanışlıdır (ama doğrulanmış olmalıdır).\n- imzalı bir JWT (veya oturum) içerir, bu da kurcalamayı zorlaştırır.\n\nBir kaynak doğrusu seçin ve her yerde loglayın. Birden fazla sinyali (subdomain + token gibi) destekliyorsanız, önceliği tanımlayın ve belirsiz istekleri reddedin.\n\n### İstek kapsamı (her sorgu nasıl kiracı içinde kalır)\n\nİyi bir kural: çözüldüğünde, tüm downstream işlemler bunu tek bir yerden (istek bağlamı) okumalı, tekrar türetmemelidir.\n\nYaygın koruyucular şunlardır:\n\n- ekleyen middleware\n- parametresi gerektiren veri erişim yardımcıları\n- Hataların kapalı başarısız olmasını sağlayan veritabanı uygulamaları (örn. satır düzeyi politikalar)\n\n\n\n(Kod bloğu olduğu için içeriği değiştirilmedi.)\n\n### Yetkilendirme temelleri (bir kiracı içindeki roller)\n\n (kullanıcının kim olduğu) (ne yapabileceği) ayırın.\n\nTipik SaaS roller Owner / Admin / Member / Read-only şeklindedir, ama anahtar nokta kapsamdır: bir kullanıcı Tenant A'da Admin, Tenant B'de Member olabilir. İzinleri global değil, tenant başına saklayın.\n\n### Çapraz-tenant sızıntılarını önleme (testler ve koruyucular)\n\nÇapraz-tenant erişimini üst seviye bir olay gibi ele alın ve proaktif olarak önleyin:\n\n- Tenant A kimliğiyle Tenant B verisini okumaya çalışan otomatik testler ekleyin\n- Eksik tenant filtre hatalarının yayımlanmasını zorlaştırın (linter'lar, sorgu yapıcıları, zorunlu tenant parametreleri)\n- Şüpheli desenlerde (örn. token ile subdomain arasında uyumsuzluk) log ve alarm kurun\n\nOperasyonel olarak daha kapsamlı bir kontrol listesi isterseniz, bu kuralları mühendislik çalışma kitaplarınıza /security altında sürümlü şekilde bağlayın.\n\n## Veritabanının Ötesinde İzolasyon\n\nVeritabanı izolasyonu hikayenin sadece yarısıdır. Birçok gerçek çok kiracılı olay uygulamanın etrafındaki paylaşılan altyapıda olur: cache'ler, kuyruklar ve depolama. Bu katmanlar hızlı, kullanışlı ve yanlışlıkla küresel yapmak kolay olan yerlerdir.\n\n### Paylaşılan cache'ler: anahtar çakışmalarını ve veri sızıntılarını önleyin\n\nBirden fazla kiracı Redis veya Memcached paylaşıyorsa, ana kural basittir: asla tenant-agnostik anahtarlar saklamayın.\n\nPratik bir desen, her anahtarı sabit bir tenant tanımlayıcısıyla prefixlemektir (email domain değil, görüntüleme adı değil). Örneğin: . Bu iki şey yapar:\n\n- İki kiracının aynı iç ID'lerine sahip olduğu durumlarda çakışmaları önler\n- Destek olayları veya taşıma sırasında toplu geçersiz kılmayı mümkün kılar (prefix ile silme)\n\nAyrıca hangi verilerin küresel olarak paylaşılabileceğini (örn. herkese açık feature flag'ler, statik metadata) kararlaştırın ve belgelenmiş tutun—kazara küresel olanlar çapraz-tenant maruziyetinin yaygın bir kaynağıdır.\n\n### Tenant farkındalıklı oran limitleri ve kotası\n\nVeriler izole olsa bile kiracılar paylaşılan hesaplama üzerinden birbirlerini etkileyebilir. Kenarda tenant farkındalıklı limitler ekleyin:\n\n- Tenant başına API oran limitleri (ve genellikle tenant içindeki kullanıcı başına)\n- İhraclar, rapor üretimi, yapay zeka çağrıları gibi pahalı işlemler için kota\n\nLimiti görünür yapın (header'lar, UI bildirimleri) ki müşteriler throttle'ın bir politika olduğunu, sistemin bozulması olmadığını anlasın.\n\n### Arka plan işleri: kuyrukları tenant bazlı bölümle\n\nTek bir paylaşılan kuyruk, bir yoğun kiracının worker zamanını domine etmesine izin verebilir.\n\nYaygın düzeltmeler:\n\n- Ücret/tier başına ayrı kuyruklar (, , )\n- Tenant ID'yi N kuyrukta hashleyerek bölümleme (partitioned queues)\n- Her kiracıya adil pay veren tenant-farkındalıklı zamanlama\n\nHer zaman job yüküne tenant bağlamını ve logları taşıyın ki yanlış tenant etkileri olmasın.\n\n### Dosya/nesne depolama: ayrı yollar, politikalar ve anahtarlar\n\nS3/GCS tarzı depolamada izolasyon genellikle path ve politika temellidir:\n\n- Katı ayrım için tenant-başına bucket (daha güçlü sınırlar, daha fazla yük)\n- Tenant prefix'li paylaşılan bucket (daha basit, dikkatli IAM ve signed URL gerektirir)\n\nHangi yöntemi seçerseniz seçin, yükleme/indirme isteklerinde her zaman tenant sahipliğini doğrulayın—sadece UI'da değil.\n\n## Gürültülü Komşuları Yönetme ve Adil Kaynak Kullanımı\n\nÇok kiracılı sistemler altyapıyı paylaştığı için bir kiracı yanlışlıkla (veya kasıtlı) diğerlerinin hakkından daha fazlasını tüketebilir. Buna gürültülü komşu problemi denir: tek bir yoğun iş yükü herkesin performansını düşürür.\n\n### Gürültülü komşu nasıl görünür\n\nBir rapor özelliğinin bir yılın verisini CSV'ye dışa aktardığını düşünün. Tenant A saat 09:00'da 20 ihracat planlar. Bu ihracatlar CPU ve veritabanı I/O'yu doyurur, bu yüzden Tenant B'nin normal uygulama ekranları zaman aşımına girer—B hiçbir şey olağan dışı yapmamasına rağmen.\n\n### Kaynak kontrolleri: limitler, kotlar ve iş yükü şekillendirme\n\nBunu önlemek açık kaynak sınırlarıyla başlar:\n\n- Her uç nokta ve kiracı için (saniye başına istek), böylece pahalı API'ler spamlenemez.\n- İhraclar, e-postalar, AI çağrıları veya arka plan işleri için (günlük/aylık toplamlar).\n- Ağır görevleri (ihracatlar, içe aktarmalar, yeniden indeksleme) per-tenant eşzamanlılık kısıtları ve öncelik kuralları olan kuyruklara koyan .\n\nPratik bir desen, etkileşimli trafiği toplu işlerden ayırmaktır: kullanıcıya yönelik istekleri hızlı yolda tutun ve diğer her şeyi kontrollü kuyruklara itin.\n\n### Tenant başına devre kesiciler ve bulkhead'ler\n\nBir kiracı bir eşiği aştığında tetiklenen güvenlik valfleri ekleyin:\n\n- bir kiracı için hata oranı, gecikme veya kuyruk derinliği eşiklerini aştığında maliyetli işlemleri geçici olarak reddetmek veya ertelemek.\n- paylaşılan havuzları (DB bağlantıları, worker thread'ler, cache) izole ederek bir kiracının küresel kapasiteyi tüketmesini engellemek.\n\nİyi yapıldığında, Tenant A kendi ihracat hızını düşürebilir ama Tenant B etkilenmez.\n\n### Bir kiracıyı adanmış kapasiteye ne zaman taşımalı\n\nBir kiracıyı sürekli olarak paylaşılan varsayımları aşarken taşıyın: sürekli yüksek throughput, tahmin edilemez zirveler, iş açısından kritik olaylarla ilişkili dalgalanmalar, sıkı uyumluluk ihtiyaçları veya özel ayar gereksinimleri. Basit bir kural: diğer kiracıları korumak için ücretli bir müşteriyi sürekli sınırlandırmanız gerekiyorsa, sürekli yangın söndürmek yerine adanmış kapasiteye (veya daha yüksek bir plana) taşıma zamanı gelmiştir.\n\n## Çok Kiracılı SaaS'te İşe Yarayan Ölçeklendirme Desenleri\n\nÇok kiracılı ölçeklendirme “daha fazla sunucu”dan ziyade bir kiracının büyümesinin herkesi şaşırtmamasını sağlamaktır. En iyi desenler ölçeği öngörülebilir, ölçülebilir ve geri alınabilir kılar.\n\n### Durumsuz servisler için yatay ölçeklendirme\n\nWeb/API katmanınızı durumsuz (stateless) yaparak başlayın: oturumları paylaşılan cache'e koyun (veya token tabanlı auth kullanın), yüklemeleri nesne depolamada tutun ve uzun süren işleri arka plan işlerine gönderin. İstekler yerel bellek veya diske bağlı olmadığında, bir yük dengeleyici arkasına örnek ekleyip hızla ölçeklendirebilirsiniz.\n\nPratik ipucu: tenant bağlamını kenarda tutun (subdomain veya header'dan türetilmiş) ve her istek işleyicisine iletin. Durumsuz, tenant-farkındalığı bırakmaz—sadece sticky server gerektirmez.\n\n### Tenant başına hotspot'lar: tanımlama ve düzleştirme\n\nÇoğu ölçek problemi “bir kiracı farklı” olmasından kaynaklanır. Aşağıdaki hotspot'lara dikkat edin:\n\n- Tek bir kiracının aşırı trafik üretmesi\n- Çok büyük veri setine sahip birkaç kiracı\n- Toplu kullanım (ay sonu raporları, gece içe aktarma)\n\nDüzleştirme taktikleri arasında tenant başına oran limitleri, kuyruk tabanlı alım, tenant-özel okuma yolları için önbellekleme ve ağır kiracıların ayrı worker havuzlarına shard edilmesi vardır.\n\n### Okuma replikaları, partitioning ve asenkron iş yükleri\n\nOkuma-yoğun iş yükleri (paneller, arama, analiz) için read replica'lar kullanın ve yazmaları primerde tutun. Partitioning (tenant, zaman veya her ikisiyle) indeksleri küçültür ve sorguları hızlandırır. Pahalı görevler—ihracatlar, ML scoring, webhook'lar—için asenkron işler tercih edin ve idempotentlik sağlayın ki retry'lar yükü katlamasın.\n\n### Kapasite planlama sinyalleri ve basit eşikler\n\nSinyalleri basit ve tenant-farkındalıklı tutun: p95 gecikme, hata oranı, kuyruk derinliği, DB CPU ve tenant başına istek hızı. Önemsiz eşiği kolay ayarla (örn. “kuyruk derinliği > N 10 dakika” veya “p95 > X ms”) ve otomatik ölçeklendirme ya da geçici tenant kısıtları tetikleyin—diğer kiracılar hissetmeden önce.\n\n## Tenant Bazlı Gözlemlenebilirlik ve Operasyonlar\n\nÇok kiracılı sistemler genellikle önce küresel olarak değil, bir kiracı, bir plan seviyesi veya bir gürültülü iş yükü için başarısız olur. Loglarınız ve panelleriniz “hangi kiracı etkilendi?” sorusuna saniyeler içinde cevap veremiyorsa, nöbet süresi tahmin-üzerine döner.\n\n### Tenant-farkındalıklı loglar, metrikler ve izler\n\nTelemetride tutarlı bir tenant bağlamı ile başlayın:\n\n- her istek ve arka plan işinde , ve stabil bir (kullanıcı/servis) ekleyin.\n- varsayılan olarak en azından tenant tier'a göre () ve yüksek seviye uç nokta bazında sayaçlar ve gecikme histogramları yayınlayın.\n- tenant bağlamını trace attribute olarak taşıyın ki yavaş bir trace'i belirli bir kiracıya filtreleyip zamanın nerede geçtiğini görebilesiniz (DB, cache, üçüncü taraf çağrılar).\n\nKardinaliteyi kontrol altında tutun: tüm kiracılar için per-tenant metrikler pahalı olabilir. Yaygın bir uzlaşı, varsayılan olarak tier-seviyesinde metrikler ve talep üzerine per-tenant inceleme (örn. “trafikte en üst 20 kiracı” veya “SLO'yu ihlal eden kiracılardan örnekleme”) yapmaktır.\n\n### Telemetride hassas veri sızıntısından kaçınma\n\nTelemetri bir veri dışa aktarma kanalıdır. Onu prod veri gibi ele alın.\n\n isimler, e-postalar, tokenlar veya sorgu payload'ları yerine loglayın. Logger/SDK katmanında redaksiyon uygulayın ve yaygın sır saklayıcıları (Authorization header, API anahtarları) kara listeleyin. Destek iş akışları için debug payload'larını ayrı, erişim kontrollü bir sistemde saklayın—paylaşılan loglarda değil.\n\n### Tier bazlı SLO'lar (aşırı söz vermeden)\n\nGerçekten sağlayabileceğiniz SLO'ları tanımlayın. Premium kiracılar daha sıkı gecikme/hata bütçesi alabilir, ama yalnızca kontrolünüz (oran limitleri, iş yükü izolasyonu, öncelik kuyrukları) varsa. Tier SLO'larını hedef olarak yayınlayın ve bunları tier bazında ve seçilmiş yüksek değerli kiracılar için izleyin.\n\n### Nöbet çalışma kitapları: çok kiracılı SaaS'te yaygın olaylar\n\nRunbook'larınız “etkilenen kiracıyı belirle” ile başlamalı ve ardından en hızlı izole edici eylemi içermelidir:\n\n1. kiracıyı throttle edin, ağır işleri duraklatın veya daha düşük öncelikli kuyruğa taşıyın.\n2. sorgu zaman aşımlarını etkinleştirin, kiracıya göre en yoğun sorguları inceleyin, indeks uygulayın veya uç noktayı kısıtlayın.\n3. hemen feature flag'i veya uç noktayı devre dışı bırakın ve erişim kontrollerinde tenant kapsamını doğrulayın.\n4. tenant başına kuyrukları boşaltın, eşzamanlılığı sınırlayın ve idempotentlik korumalarıyla yeniden oynatın.\n\nOperasyonel amaç basit: kiracıya göre tespit et, kiracıya göre izole et ve herkesi etkilemeden kurtar.\n\n## Dağıtımlar, Migrasyonlar ve Kiracı Bazlı Sürümler\n\nÇok kiracılı SaaS, yayınlama ritmini değiştirir. Siz bir “uygulama” dağıtmıyorsunuz; birçok müşterinin aynı anda bağımlı olduğu paylaşılan çalışma zamanı ve paylaşılan veri yollarını dağıtıyorsunuz. Amaç yeni özellikleri tek seferlik büyük bir yükseltme zorunluluğu olmadan teslim etmektir.\n\n### Rolling deploy'lar ve düşük kesintiyle migrasyonlar\n\nKarışık sürümlere kısa bir pencere tolerans gösteren dağıtım desenlerini tercih edin (blue/green, canary, rolling). Bu, veritabanı değişiklikleriniz de aşamalıysa işe yarar.\n\nPratik bir kural: :\n\n- yeni sütunlar/tablolar/index'ler ekleyin, mevcut kodu kırmadan.\n- veriyi partiler halinde backfill yapın (çoğunlukla tenant bazında) ve doğrulayın.\n- tüm uygulama örnekleri artık eski alanlara ihtiyaç duymadığında eski alanları kaldırın.\n\nSıcak tablolarda backfill'leri kademeli (ve throttle edilmiş) yapın; aksi takdirde migration sırasında kendi gürültülü-komşu olayınızı yaratırsınız.\n\n### Kiracı düzeyinde feature flag'ler ile daha güvenli yayınlar\n\nTenant düzeyinde feature flag'ler, kodu küresel olarak dağıtırken davranışı seçici olarak etkinleştirmenizi sağlar.\n\nBunun desteklediği şeyler:\n\n- Birkaç kiracı için erken erişim programları\n- Etkilenen kiracılar için yalnızca özelliği devre dışı bırakarak hızlı geri dönüş\n- Dağıtımları çatallamadan A/B deneyleri\n\nFlag sisteminin denetlenebilir olmasına dikkat edin: kim neyi, hangi kiracı için ve ne zaman etkinleştirdi.\n\n### Sürümleme ve geriye dönük uyumluluk beklentileri\n\nBazı kiracıların konfigürasyon, entegrasyon veya kullanım kalıplarında geride kalabileceğini varsayın. Yeni üreticiler eski tüketicileri bozmaması için API'leri ve event'leri açık sürümlendirme ile tasarlayın.\n\nİç beklentilere örnekler:\n\n- Yeni sürümler migration penceresinde hem eski hem yeni veri şekillerini okuyabilmeli.\n- Deprecation'lar yayımlanmış bir zaman çizelgesi gerektirir (en azından iç notlar ve müşteri e-posta şablonu).\n\n### Kiracı-özgü konfigürasyon yönetimi\n\nKiracı konfigürasyonunu bir ürün yüzeyi olarak ele alın: doğrulama, varsayılanlar ve değişiklik geçmişi gerektirir.\n\nKonfigürasyonu koddan ayrı saklayın (tercihen çalışma zamanı sırlarından da ayrı) ve konfigürasyon geçersizse güvenli mod fallback destekleyin. /settings/tenants benzeri hafif bir internal sayfa, olay yanıtı ve kademeli dağıtım sırasında saatler kazandırabilir.\n\n## Yapay Zeka Tarafından Üretilen Mimariler Nasıl Yardımcı Olur (ve Sınırları)\n\nYapay zeka, çok kiracılı SaaS için erken mimari düşünmeyi hızlandırabilir, ama mühendislik yargısının, testlerin veya güvenlik incelemesinin yerine geçmez. Onu yüksek kalitede bir beyin fırtınası ortağı olarak görün—taslaklar üretir, sonra her varsayımı doğrulayın.\n\n### Yapay zeka tarafından üretilen mimari ne yapmalı (ve ne yapmamalı)\n\nYapay zeka, seçenekler üretmekte ve tipik başarısızlık modlarını vurgulamakta (kiracı bağlamının nerede kaybolabileceği veya paylaşılan kaynakların sürpriz yaratabileceği yerler gibi) işe yarar. Ancak modelinizi seçmemeli, uyumluluğu garanti etmemeli ya da performansı doğrulamamalıdır. Gerçek trafiğinizi, ekibinizin yeteneklerini veya miras entegrasyonlardaki uç durumları göremez.\n\n### Önemli girdiler: gereksinimler, kısıtlar, riskler, büyüme\n\nÇıktının kalitesi verdiğiniz girdilere bağlıdır. Faydalı girdiler arasında:\n\n- Bugünkü ve 12–24 ay içindeki beklenen kiracı sayısı ile kiracı başına veri hacmi\n- İzolasyon gereksinimleri (sözleşmesel, düzenleyici, müşteri beklentileri)\n- Bütçe ve operasyonel kapasite (on-call olgunluğu, SRE desteği, araçlar)\n- Gecikme hedefleri, pik kullanım desenleri ve kiracı bazlı patlamalar\n- Risk toleransı: bir kiracı diğerini etkilerse ne olur?\n\n### Yapay zekayı desen seçenekleri ve takaslar için kullanma\n\n2–4 aday tasarım isteyin (ör. tenant-başına veritabanı vs şema vs satır düzeyi izolasyon) ve açık bir takas tablosu talep edin: maliyet, operasyonel karmaşıklık, patlama yarıçapı, migration çabası ve ölçek sınırları. Yapay zeka, ekip için tasarım sorularına dönüştürebileceğiniz tuzakları listelemede iyidir.\n\nTaslak mimariden çalışan bir prototipe daha hızlı geçmek isterseniz, Koder.ai gibi vibe-coding platformları bu seçimleri gerçek bir uygulama iskeletine çevirmenize yardımcı olabilir—çoğunlukla React frontend ve Go + PostgreSQL backend ile—böylece tenant bağlamı yayılımını, oran limitlerini ve migration iş akışlarını daha erken doğrulayabilirsiniz. Planning mode ve snapshot/rollback gibi özellikler çok kiracılı veri modellerinde iterasyon yaparken özellikle yararlıdır.\n\n### Yapay zekayı tehdit modelleri ve kontrol listeleri üretmede kullanma\n\nYapay zeka basit bir tehdit modeli taslağı çıkarabilir: giriş noktaları, güven sınırları, kiracı-bağlamı yayılımı ve yaygın hatalar (ör. arka plan işlerinde eksik yetkilendirme kontrolleri). Bunu PR'lar için inceleme kontrol listeleri ve runbook'lar üretmekte kullanın—ama gerçek güvenlik uzmanlığı ve kendi olay geçmişinizle doğrulayın.\n\n## Ekibiniz İçin Pratik Seçim Kontrol Listesi\n\nÇok kiracılı yaklaşım seçmek “en iyi uygulama”dan çok uygunluğa bağlıdır: veri duyarlılığı, büyüme hızı ve taşıyabileceğiniz operasyonel karmaşıklık.\n\n### Adım adım kontrol listesi (30 dakikalık bir workshop'ta kullanın)\n\n1) Hangi veriler kiracılar arasında paylaşılıyor (varsa)? Hangi veriler asla birlikte tutulmamalı?\n\n2) Kiracı kimliği nerede yaşıyor (davet linkleri, domainler, SSO claim'leri)? Her istekte kiracı bağlamı nasıl kuruluyor?\n\n3) Varsayılan izolasyon seviyenizi belirleyin (satır/şema/veritabanı) ve istisnaları tanımlayın (ör. enterprise müşteriler için daha güçlü ayrıma ihtiyaç).\n\n4) İlk beklenen ölçeklenme baskısını belirleyin (depolama, okuma trafiği, arka plan işleri, analiz) ve bunu karşılayan en basit deseni seçin.\n\n### Mühendisler ve güvenlik inceleyicilerle doğrulanması gereken sorular\n\n- Bir geliştirici filtreyi unutursa çapraz-tenant erişimi nasıl engelleriz?\n- Tenant başına denetim hikayemiz nedir (kim ne zaman ne yaptı)?\n- Tenant bazlı veri silme ve saklama nasıl ele alınır?\n- Kötü bir migration veya kaçışan sorgunun patlama yarıçapı nedir?\n- Kaynakları tenant başına throttle, oran-limits ve bütçeleyebilir miyiz?\n\n### Daha derin tasarım gerektiren kırmızı bayraklar\n\n- “Tenant kontrollerini sonra ekleriz.”\n- Her şeyi görebilen paylaşılan admin araçları ama sıkı kontroller yok.\n- Kiracı başına yedek/geri yükleme veya olay müdahale planı yok.\n\n- Per-tenant adaletsizliği engelleyecek planı olmayan tek bir kuyruk/worker havuzu.\n\n### Örnek "önerilen bir sonraki adım" özeti\n\n Satır düzeyi izolasyonla başlayın + sıkı kiracı-bağlamı uygulaması ekleyin, tenant başına throttle'lar koyun ve yüksek riskli kiracılar için şema/veritabanı izolasyonuna yükseltme yolu tanımlayın.\n\n kiracı sınırlarında tehdit-modeli çıkarın, bir uç noktada zorlayıcı uygulama prototipi yapın ve staging kopyasında migration provasını çalıştırın. Dağıtım kılavuzu için /blog/tenant-release-strategies notlarını referans alın.",