Bölüm 26 / 33
Mimari, Ölçeklenebilirlik ve Çok Kiracılı Sistemler
Uygulama bileşenlerinin sınırları, dağıtık sistem tasarımı, ölçekleme ve SaaS tenant izolasyonu.
3 canlı örnek — seçerek incele
İlgili kavramlar: Monolith, Microservice, Architecture
Monolit vs servisler
Bir sistemin bileşenlerini, sorumluluklarını ve aralarındaki ilişkileri belirleyen üst düzey yapı.
Gereksinimlere göre veri, servis, ağ, ölçek ve hata davranışlarını tasarlama süreci.
Sistemin sağlaması gereken işlev veya kalite beklentisi.
Sistemin yapması gereken belirli işlev.
Performans, güvenlik, ölçek ve kullanılabilirlik gibi kalite şartı.
Teknoloji, bütçe, mevzuat veya süre nedeniyle tasarımı sınırlayan koşul.
Bir tasarım avantajı karşılığında başka bir özellikten ödün verme.
Uygulama modüllerinin tek deploy birimi ve süreçte çalıştığı mimari.
Tek deploy içinde net modül sınırları ve bağımlılık kuralları bulunan monolith.
Bileşenlerin ağ üzerinden farklı süreç veya makinelerde birlikte çalıştığı sistem.
Belirli iş kabiliyetine sahip bağımsız deploy edilebilir küçük servis.
Bir servisin sahip olduğu veri, kurallar ve sorumlulukların sınırı.
Domain kavramlarının belirli model ve anlamla tutarlı olduğu sınır.
Yazılım modelini iş alanı dili ve sınırları etrafında tasarlama yaklaşımı.
İş ve teknik ekiplerin aynı domain terimlerini tutarlı kullanması.
Presentation, application, domain ve data gibi katmanlara ayrılan yapı.
İş kurallarını framework ve dış sistemlerden bağımsız tutan katmanlı yaklaşım.
Uygulama çekirdeğini port ve adapter'larla dış sistemlerden ayırır.
- PortO
Uygulama çekirdeğinin dış dünya ile iletişim sözleşmesi.
Bir portu HTTP, database veya queue teknolojisiyle uygulayan bileşen.
- MVCT
Model, View ve Controller sorumluluklarını ayıran arayüz mimarisi.
- MVVMO
View, ViewModel ve model ile özellikle UI uygulamalarında kullanılan desen.
- CQRSİ
Okuma ve yazma modellerini ayrı sorumluluk ve modeller olarak tasarlama.
Sistemde durum değiştirme niyetini temsil eden istek.
Sistem durumunu değiştirmeden veri okuma isteği.
Mevcut durumu saklamak yerine tüm domain değişiklik olaylarını kaynak olarak saklama.
Tutarlılık sınırı içinde birlikte değişen entity ve value object grubu.
Aggregate dışından erişilen ve kuralları koruyan ana entity.
İş alanında gerçekleşmiş anlamlı olayı temsil eden kayıt.
Uygulama katmanındaki teknik veya süreç olayını temsil eder.
Başka servislerin tüketmesi için yayınlanan dış sistem olayı.
Ürün arayüzlerinden önce API sözleşmesini temel alan geliştirme yaklaşımı.
Servis iletişimini uygulamadan önce OpenAPI veya proto sözleşmesiyle tanımlama.
Web, mobil veya partner istemci için özel backend katmanı.
Servislerin önünde routing, auth, rate limit ve gözlem sağlayan katman.
Servisler arası ağ iletişimine mTLS, retry ve telemetry sağlayan altyapı katmanı.
Ana uygulama container'ıyla aynı çalışma biriminde yardımcı ağ veya log servisi.
Sistemin artan yükü kaynak ekleyerek karşılayabilme yeteneği.
Tek sunucunun CPU, RAM veya disk kapasitesini artırma.
Aynı servisten daha fazla instance ekleyerek kapasite artırma.
Daha güçlü makineye geçme.
Daha fazla makine veya instance ekleme.
Metrik veya talebe göre instance sayısını otomatik değiştirme.
Request'ler arasında kullanıcı durumunu yerel bellekte zorunlu tutmayan servis.
Yerel veya bağlı kalıcı durum taşıyan servis.
Trafiği birden fazla instance arasında dağıtma.
İstekleri instance'lara sırayla dağıtan algoritma.
Yeni isteği en az aktif bağlantısı olan instance'a yönlendirir.
Instance veya sürümlere farklı trafik ağırlığı verir.
Aynı kullanıcının isteklerini belirli instance'a yönlendirme.
Sticky session için kullanılan genel terim.
Bileşen arızasında hizmetin çalışmaya devam etmesini hedefleyen tasarım.
Tek hata noktasını azaltmak için bileşenlerin yedekli bulunması.
Arızalı bileşenden sağlıklı yedek bileşene geçme.
Arızası tüm sistemi durdurabilecek tek bileşen.
Bazı bileşenler arızalansa da sistemin doğru hizmet vermeye devam etmesi.
Hata, gecikme ve yük değişikliklerinden toparlanabilme yeteneği.
Bazı özellikler arızalandığında çekirdek hizmeti sınırlı biçimde sürdürme.
Bir kaynaktaki aşırı kullanımın diğer iş yüklerini batırmasını izolasyonla önleme.
Sürekli hata veren bağımlılığa çağrıları geçici durdurma.
Bir bağımlılık yanıtı için maksimum bekleme süresi.
Geçici hatada işlemi yeniden deneme.
Çok sayıda istemcinin aynı arızalı servisi tekrar deneyerek yükü artırması.
Tekrar denemeler arasında giderek artan bekleme uygulama.
Tekrar deneme zamanlarını rastgele dağıtarak eşzamanlı yığılmayı azaltma.
Kullanıcı veya servisin bir sürede yapabileceği işlem sayısını sınırlar.
Belirli dönem için toplam kullanım hakkı.
Aşırı trafiği reddetme veya yavaşlatma.
Tüketici kapasitesi yetersizken üreticinin veri hızını azaltması.
Beklenen trafik ve büyümeye göre kaynak ihtiyacını hesaplama.
Belirli dönemde görülen en yüksek trafik veya iş yükü.
Sistemin normal koşullardaki tipik iş yükü.
Birden fazla işlemin zaman bakımından üst üste ilerlemesi.
Birden fazla işlemin aynı anda farklı işlem birimlerinde çalışması.
Birim zamanda tamamlanan iş veya request sayısı.
Tek işlemin tamamlanma süresi.
İsteklerin yüzde 95'inin altında tamamlandığı gecikme.
Bir kaynağın kapasite sınırına ne kadar yaklaştığı.
Sistem kapasitesini sınırlayan en yavaş kaynak veya aşama.
CPU, bellek ve fonksiyon maliyetlerini ölçerek darboğaz bulma.
Belirli iş yükünde karşılaştırılabilir performans ölçümü.
Sık kullanılan veriyi daha hızlı katmanda geçici saklama.
Uygulamanın önce cache'e bakıp yoksa veri kaynağından alarak cache'e yazması.
Cache katmanının eksik veriyi veri kaynağından otomatik yüklemesi.
Yazmanın cache ve kalıcı depoya birlikte uygulanması.
Yazının önce cache'e, kalıcı depoya daha sonra asenkron uygulanması.
Değişmiş veriye ait eski cache kaydını kaldırma.
Popüler cache kaydı süresi dolunca çok sayıda isteğin aynı anda kaynağa gitmesi.
Trafik gelmeden önemli cache kayıtlarını önceden doldurma.
- TTLT
Cache kaydının geçerlilik süresi.
Bellek dolduğunda hangi cache kayıtlarının silineceğini belirler.
- LRUO
En uzun süredir kullanılmayan kaydı önce çıkaran politika.
Birden fazla uygulama instance'ının paylaştığı cache sistemi.
Farklı kopya ve servislerde verinin uyum düzeyi.
Yazma tamamlandıktan sonra tüm okumaların en güncel değeri görmesi.
Kopyaların kısa süre farklı olup sonunda aynı duruma gelmesi.
Kullanıcının kendi yaptığı yazmayı sonraki okumada görebilmesi garantisi.
Dağıtık sistemde partition sırasında consistency ve availability arasında seçim gerektiğini ifade eder.
Dağıtık düğümlerin ağ nedeniyle birbirleriyle iletişim kuramaması.
Birden fazla servis veya veri kaynağında atomiklik sağlamaya çalışan işlem.
Katılımcıların prepare ve commit aşamalarıyla ortak transaction kararı verdiği protokol.
Dağıtık iş sürecini yerel transaction ve telafi işlemleri dizisiyle yönetme.
Önceki adımın iş etkisini geri alan domain işlemi.
Merkezi bileşenin saga adımlarını ve telafileri yönetmesi.
Servislerin olaylarla birbirini tetikleyerek merkezi yönetici olmadan ilerlemesi.
Aynı komut tekrarlandığında ek yan etki oluşmaması.
Tekrarlanan mesaj veya işlemleri kimlikle tespit edip bir kez uygulama.
İş etkisinin tam bir kez oluşmasını hedefleyen, genellikle idempotency ile sağlanan garanti.
Mesajın kaybolmamasını sağlarken birden fazla teslim ihtimaline izin verir.
Mesajın en fazla bir kez teslim edilmesini, kaybolma ihtimaliyle birlikte kabul eder.
Tek uygulama platformunda birden fazla müşteri organizasyonunun hizmet alması.
SaaS sistemi içindeki bağımsız müşteri, organizasyon veya mağaza.
Her kaydı ait olduğu tenant ile ilişkilendiren kimlik.
Mevcut request ve işlemin hangi tenant adına çalıştığını belirleyen bağlam.
Tenant'ı subdomain, domain, token veya kullanıcı ilişkisinden belirleme.
Her tenant'ın tenant.example.com adresiyle ayrıldığı model.
Tenant'ın kendi domainini SaaS mağaza veya uygulamasına bağlaması.
Her tenant'a bağımsız veritabanı verilen izolasyon modeli.
Bir tenant'ın veri ve işlemlerinin başka tenant'a sızmamasını garanti eden kurallar.
Veritabanının satır erişimini session veya policy ile tenant/kullanıcıya göre sınırlar.
Bir tenant'ın aşırı kaynak tüketiminin diğer tenant'ları yavaşlatması.
Tenant başına kullanıcı, depolama veya API kullanım sınırı.
SaaS özellik ve limitlerini belirleyen abonelik seviyesi.
Tenant planının hangi özelliği kullanabileceğini belirleyen hak.
Müşteriye özel tema, domain, vergi ve davranış ayarları.
Tenant'a ait logo, renk ve marka görünümü.
Yeni tenant için kayıt, domain, varsayılan veri ve kaynakları hazırlama.
Müşterinin SaaS sistemine ilk kurulum ve veri giriş süreci.
İptal edilen tenant verisini export, saklama ve silme politikasıyla kapatma.
Tenant verisinin belirli ülke veya bölgede saklanması gereksinimi.
Tenant planı, kullanım ve yenileme ücretlerinin yönetimi.
API çağrısı, kullanıcı veya depolama miktarına göre ücretlendirme.
Faturalandırılacak kullanım miktarlarını ölçme ve kaydetme.
İşlem öncesi tenant planının özelliğe izin verip vermediğini doğrulama.
Tenant, deployment, policy ve configuration yönetimini yapan merkezi katman.
Gerçek kullanıcı trafiği ve iş verisinin işlendiği çalışma katmanı.
Uygulama ve verinin birden fazla coğrafi bölgede dağıtılması.
Hizmetin aktif veya yedek olarak birden fazla bölgede çalışması.
Birden fazla bölgenin aynı anda trafik kabul ettiği mimari.
Ana bölge hizmet verirken yedek bölgenin failover için hazır beklemesi.
Büyük arıza sonrası hizmet ve veriyi geri getirme planı.
- RTOO
Arıza sonrası hizmetin kabul edilebilir maksimum geri dönüş süresi.
- RPOO
Arıza durumunda kaybedilebilecek maksimum veri süresi.
Yedek sıklığı, hedefi, retention ve geri yükleme testlerini belirleyen plan.
Yedeklerin gerçekten geri döndürülebildiğini periyodik uygulamayla doğrulama.
Önemli mimari karar, alternatif ve gerekçeyi kısa belgeyle kaydetme.
Bir özelliğin veri modeli, API, akış, risk ve dağıtım tasarımını açıklar.
Bileşenler arasındaki mesajların zaman sırasını gösterir.
Sistem bileşenleri ve bağımlılıklarını gösterir.
Uygulama bileşenlerinin sunucu, container ve ağ üzerinde yerleşimini gösterir.
Verinin süreçler ve depolar arasındaki hareketini gösterir.
Sistemi context, container, component ve code seviyelerinde görselleştirme yaklaşımı.
| Kavram | Seviye | Kısa açıklama |
|---|---|---|
| Software Architecture | T | Bir sistemin bileşenlerini, sorumluluklarını ve aralarındaki ilişkileri belirleyen üst düzey yapı. |
| System Design | O | Gereksinimlere göre veri, servis, ağ, ölçek ve hata davranışlarını tasarlama süreci. |
| Requirement | T | Sistemin sağlaması gereken işlev veya kalite beklentisi. |
| Functional Requirement | T | Sistemin yapması gereken belirli işlev. |
| Non-functional Requirement | T | Performans, güvenlik, ölçek ve kullanılabilirlik gibi kalite şartı. |
| Constraint | T | Teknoloji, bütçe, mevzuat veya süre nedeniyle tasarımı sınırlayan koşul. |
| Trade-off | O | Bir tasarım avantajı karşılığında başka bir özellikten ödün verme. |
| Monolith | T | Uygulama modüllerinin tek deploy birimi ve süreçte çalıştığı mimari. |
| Modular Monolith | O | Tek deploy içinde net modül sınırları ve bağımlılık kuralları bulunan monolith. |
| Distributed System | O | Bileşenlerin ağ üzerinden farklı süreç veya makinelerde birlikte çalıştığı sistem. |
| Microservice | O | Belirli iş kabiliyetine sahip bağımsız deploy edilebilir küçük servis. |
| Service Boundary | İ | Bir servisin sahip olduğu veri, kurallar ve sorumlulukların sınırı. |
| Bounded Context | İ | Domain kavramlarının belirli model ve anlamla tutarlı olduğu sınır. |
| Domain-driven Design | İ | Yazılım modelini iş alanı dili ve sınırları etrafında tasarlama yaklaşımı. |
| Ubiquitous Language | O | İş ve teknik ekiplerin aynı domain terimlerini tutarlı kullanması. |
| Layered Architecture | T | Presentation, application, domain ve data gibi katmanlara ayrılan yapı. |
| Clean Architecture | O | İş kurallarını framework ve dış sistemlerden bağımsız tutan katmanlı yaklaşım. |
| Hexagonal Architecture | O | Uygulama çekirdeğini port ve adapter'larla dış sistemlerden ayırır. |
| Port | O | Uygulama çekirdeğinin dış dünya ile iletişim sözleşmesi. |
| Adapter | O | Bir portu HTTP, database veya queue teknolojisiyle uygulayan bileşen. |
| MVC | T | Model, View ve Controller sorumluluklarını ayıran arayüz mimarisi. |
| MVVM | O | View, ViewModel ve model ile özellikle UI uygulamalarında kullanılan desen. |
| CQRS | İ | Okuma ve yazma modellerini ayrı sorumluluk ve modeller olarak tasarlama. |
| Command | O | Sistemde durum değiştirme niyetini temsil eden istek. |
| Query | O | Sistem durumunu değiştirmeden veri okuma isteği. |
| Event Sourcing | İ | Mevcut durumu saklamak yerine tüm domain değişiklik olaylarını kaynak olarak saklama. |
| Aggregate | İ | Tutarlılık sınırı içinde birlikte değişen entity ve value object grubu. |
| Aggregate Root | İ | Aggregate dışından erişilen ve kuralları koruyan ana entity. |
| Domain Event | O | İş alanında gerçekleşmiş anlamlı olayı temsil eden kayıt. |
| Application Event | O | Uygulama katmanındaki teknik veya süreç olayını temsil eder. |
| Integration Event | O | Başka servislerin tüketmesi için yayınlanan dış sistem olayı. |
| API-first | O | Ürün arayüzlerinden önce API sözleşmesini temel alan geliştirme yaklaşımı. |
| Contract-first | O | Servis iletişimini uygulamadan önce OpenAPI veya proto sözleşmesiyle tanımlama. |
| Backend for Frontend | O | Web, mobil veya partner istemci için özel backend katmanı. |
| API Gateway | O | Servislerin önünde routing, auth, rate limit ve gözlem sağlayan katman. |
| Service Mesh | İ | Servisler arası ağ iletişimine mTLS, retry ve telemetry sağlayan altyapı katmanı. |
| Sidecar | İ | Ana uygulama container'ıyla aynı çalışma biriminde yardımcı ağ veya log servisi. |
| Scalability | T | Sistemin artan yükü kaynak ekleyerek karşılayabilme yeteneği. |
| Vertical Scaling | T | Tek sunucunun CPU, RAM veya disk kapasitesini artırma. |
| Horizontal Scaling | T | Aynı servisten daha fazla instance ekleyerek kapasite artırma. |
| Scale Up | T | Daha güçlü makineye geçme. |
| Scale Out | T | Daha fazla makine veya instance ekleme. |
| Autoscaling | O | Metrik veya talebe göre instance sayısını otomatik değiştirme. |
| Stateless Service | O | Request'ler arasında kullanıcı durumunu yerel bellekte zorunlu tutmayan servis. |
| Stateful Service | O | Yerel veya bağlı kalıcı durum taşıyan servis. |
| Shared-nothing Architecture | İ | Her node'un bağımsız kaynaklarla çalışıp ortak darboğazı azaltması. |
| Load Balancing | T | Trafiği birden fazla instance arasında dağıtma. |
| Round Robin | T | İstekleri instance'lara sırayla dağıtan algoritma. |
| Least Connections | O | Yeni isteği en az aktif bağlantısı olan instance'a yönlendirir. |
| Weighted Routing | O | Instance veya sürümlere farklı trafik ağırlığı verir. |
| Sticky Session | O | Aynı kullanıcının isteklerini belirli instance'a yönlendirme. |
| Session Affinity | O | Sticky session için kullanılan genel terim. |
| High Availability | O | Bileşen arızasında hizmetin çalışmaya devam etmesini hedefleyen tasarım. |
| Redundancy | T | Tek hata noktasını azaltmak için bileşenlerin yedekli bulunması. |
| Failover | O | Arızalı bileşenden sağlıklı yedek bileşene geçme. |
| Single Point of Failure | T | Arızası tüm sistemi durdurabilecek tek bileşen. |
| Fault Tolerance | İ | Bazı bileşenler arızalansa da sistemin doğru hizmet vermeye devam etmesi. |
| Resilience | O | Hata, gecikme ve yük değişikliklerinden toparlanabilme yeteneği. |
| Graceful Degradation | O | Bazı özellikler arızalandığında çekirdek hizmeti sınırlı biçimde sürdürme. |
| Bulkhead Pattern | İ | Bir kaynaktaki aşırı kullanımın diğer iş yüklerini batırmasını izolasyonla önleme. |
| Circuit Breaker | İ | Sürekli hata veren bağımlılığa çağrıları geçici durdurma. |
| Timeout | T | Bir bağımlılık yanıtı için maksimum bekleme süresi. |
| Retry | O | Geçici hatada işlemi yeniden deneme. |
| Retry Storm | İ | Çok sayıda istemcinin aynı arızalı servisi tekrar deneyerek yükü artırması. |
| Backoff | O | Tekrar denemeler arasında giderek artan bekleme uygulama. |
| Jitter | İ | Tekrar deneme zamanlarını rastgele dağıtarak eşzamanlı yığılmayı azaltma. |
| Rate Limiting | O | Kullanıcı veya servisin bir sürede yapabileceği işlem sayısını sınırlar. |
| Quota | O | Belirli dönem için toplam kullanım hakkı. |
| Throttling | O | Aşırı trafiği reddetme veya yavaşlatma. |
| Backpressure | İ | Tüketici kapasitesi yetersizken üreticinin veri hızını azaltması. |
| Capacity Planning | O | Beklenen trafik ve büyümeye göre kaynak ihtiyacını hesaplama. |
| Peak Load | T | Belirli dönemde görülen en yüksek trafik veya iş yükü. |
| Baseline Load | T | Sistemin normal koşullardaki tipik iş yükü. |
| Concurrency | O | Birden fazla işlemin zaman bakımından üst üste ilerlemesi. |
| Parallelism | O | Birden fazla işlemin aynı anda farklı işlem birimlerinde çalışması. |
| Throughput | T | Birim zamanda tamamlanan iş veya request sayısı. |
| Latency | T | Tek işlemin tamamlanma süresi. |
| p95 Latency | O | İsteklerin yüzde 95'inin altında tamamlandığı gecikme. |
| Saturation | O | Bir kaynağın kapasite sınırına ne kadar yaklaştığı. |
| Bottleneck | T | Sistem kapasitesini sınırlayan en yavaş kaynak veya aşama. |
| Profiling | O | CPU, bellek ve fonksiyon maliyetlerini ölçerek darboğaz bulma. |
| Benchmark | O | Belirli iş yükünde karşılaştırılabilir performans ölçümü. |
| Caching | T | Sık kullanılan veriyi daha hızlı katmanda geçici saklama. |
| Cache Aside | O | Uygulamanın önce cache'e bakıp yoksa veri kaynağından alarak cache'e yazması. |
| Read-through Cache | O | Cache katmanının eksik veriyi veri kaynağından otomatik yüklemesi. |
| Write-through Cache | O | Yazmanın cache ve kalıcı depoya birlikte uygulanması. |
| Write-behind Cache | İ | Yazının önce cache'e, kalıcı depoya daha sonra asenkron uygulanması. |
| Cache Invalidation | O | Değişmiş veriye ait eski cache kaydını kaldırma. |
| Cache Stampede | İ | Popüler cache kaydı süresi dolunca çok sayıda isteğin aynı anda kaynağa gitmesi. |
| Cache Warming | O | Trafik gelmeden önemli cache kayıtlarını önceden doldurma. |
| TTL | T | Cache kaydının geçerlilik süresi. |
| Eviction Policy | O | Bellek dolduğunda hangi cache kayıtlarının silineceğini belirler. |
| LRU | O | En uzun süredir kullanılmayan kaydı önce çıkaran politika. |
| Distributed Cache | O | Birden fazla uygulama instance'ının paylaştığı cache sistemi. |
| Data Consistency | O | Farklı kopya ve servislerde verinin uyum düzeyi. |
| Strong Consistency | İ | Yazma tamamlandıktan sonra tüm okumaların en güncel değeri görmesi. |
| Eventual Consistency | O | Kopyaların kısa süre farklı olup sonunda aynı duruma gelmesi. |
| Read-your-writes | İ | Kullanıcının kendi yaptığı yazmayı sonraki okumada görebilmesi garantisi. |
| CAP Theorem | İ | Dağıtık sistemde partition sırasında consistency ve availability arasında seçim gerektiğini ifade eder. |
| Network Partition | İ | Dağıtık düğümlerin ağ nedeniyle birbirleriyle iletişim kuramaması. |
| Distributed Transaction | İ | Birden fazla servis veya veri kaynağında atomiklik sağlamaya çalışan işlem. |
| Two-phase Commit | İ | Katılımcıların prepare ve commit aşamalarıyla ortak transaction kararı verdiği protokol. |
| Saga Pattern | İ | Dağıtık iş sürecini yerel transaction ve telafi işlemleri dizisiyle yönetme. |
| Compensating Transaction | İ | Önceki adımın iş etkisini geri alan domain işlemi. |
| Orchestration Saga | İ | Merkezi bileşenin saga adımlarını ve telafileri yönetmesi. |
| Choreography Saga | İ | Servislerin olaylarla birbirini tetikleyerek merkezi yönetici olmadan ilerlemesi. |
| Idempotency | O | Aynı komut tekrarlandığında ek yan etki oluşmaması. |
| Deduplication | O | Tekrarlanan mesaj veya işlemleri kimlikle tespit edip bir kez uygulama. |
| Exactly-once Semantics | İ | İş etkisinin tam bir kez oluşmasını hedefleyen, genellikle idempotency ile sağlanan garanti. |
| At-least-once Delivery | O | Mesajın kaybolmamasını sağlarken birden fazla teslim ihtimaline izin verir. |
| At-most-once Delivery | O | Mesajın en fazla bir kez teslim edilmesini, kaybolma ihtimaliyle birlikte kabul eder. |
| Multi-tenancy | O | Tek uygulama platformunda birden fazla müşteri organizasyonunun hizmet alması. |
| Tenant | T | SaaS sistemi içindeki bağımsız müşteri, organizasyon veya mağaza. |
| Tenant ID | T | Her kaydı ait olduğu tenant ile ilişkilendiren kimlik. |
| Tenant Context | O | Mevcut request ve işlemin hangi tenant adına çalıştığını belirleyen bağlam. |
| Tenant Resolution | O | Tenant'ı subdomain, domain, token veya kullanıcı ilişkisinden belirleme. |
| Subdomain Tenancy | O | Her tenant'ın tenant.example.com adresiyle ayrıldığı model. |
| Custom Domain | O | Tenant'ın kendi domainini SaaS mağaza veya uygulamasına bağlaması. |
| Shared Database Shared Schema | O | Tüm tenant'ların aynı tabloları tenant_id ile paylaştığı model. |
| Shared Database Separate Schema | O | Aynı veritabanında her tenant için ayrı schema kullanılan model. |
| Database per Tenant | O | Her tenant'a bağımsız veritabanı verilen izolasyon modeli. |
| Tenant Isolation | İ | Bir tenant'ın veri ve işlemlerinin başka tenant'a sızmamasını garanti eden kurallar. |
| Row-level Security | İ | Veritabanının satır erişimini session veya policy ile tenant/kullanıcıya göre sınırlar. |
| Noisy Neighbor | İ | Bir tenant'ın aşırı kaynak tüketiminin diğer tenant'ları yavaşlatması. |
| Tenant Quota | O | Tenant başına kullanıcı, depolama veya API kullanım sınırı. |
| Tenant Plan | T | SaaS özellik ve limitlerini belirleyen abonelik seviyesi. |
| Feature Entitlement | O | Tenant planının hangi özelliği kullanabileceğini belirleyen hak. |
| Tenant Configuration | O | Müşteriye özel tema, domain, vergi ve davranış ayarları. |
| Tenant Branding | T | Tenant'a ait logo, renk ve marka görünümü. |
| Tenant Provisioning | O | Yeni tenant için kayıt, domain, varsayılan veri ve kaynakları hazırlama. |
| Tenant Onboarding | T | Müşterinin SaaS sistemine ilk kurulum ve veri giriş süreci. |
| Tenant Deprovisioning | O | İptal edilen tenant verisini export, saklama ve silme politikasıyla kapatma. |
| Data Residency | İ | Tenant verisinin belirli ülke veya bölgede saklanması gereksinimi. |
| SaaS Billing | O | Tenant planı, kullanım ve yenileme ücretlerinin yönetimi. |
| Usage-based Billing | O | API çağrısı, kullanıcı veya depolama miktarına göre ücretlendirme. |
| Metering | O | Faturalandırılacak kullanım miktarlarını ölçme ve kaydetme. |
| Entitlement Check | O | İşlem öncesi tenant planının özelliğe izin verip vermediğini doğrulama. |
| Control Plane | İ | Tenant, deployment, policy ve configuration yönetimini yapan merkezi katman. |
| Data Plane | İ | Gerçek kullanıcı trafiği ve iş verisinin işlendiği çalışma katmanı. |
| Regional Deployment | İ | Uygulama ve verinin birden fazla coğrafi bölgede dağıtılması. |
| Multi-region | İ | Hizmetin aktif veya yedek olarak birden fazla bölgede çalışması. |
| Active-active | İ | Birden fazla bölgenin aynı anda trafik kabul ettiği mimari. |
| Active-passive | İ | Ana bölge hizmet verirken yedek bölgenin failover için hazır beklemesi. |
| Disaster Recovery | O | Büyük arıza sonrası hizmet ve veriyi geri getirme planı. |
| RTO | O | Arıza sonrası hizmetin kabul edilebilir maksimum geri dönüş süresi. |
| RPO | O | Arıza durumunda kaybedilebilecek maksimum veri süresi. |
| Backup Strategy | T | Yedek sıklığı, hedefi, retention ve geri yükleme testlerini belirleyen plan. |
| Restore Drill | O | Yedeklerin gerçekten geri döndürülebildiğini periyodik uygulamayla doğrulama. |
| Architecture Decision Record | O | Önemli mimari karar, alternatif ve gerekçeyi kısa belgeyle kaydetme. |
| Technical Design Document | O | Bir özelliğin veri modeli, API, akış, risk ve dağıtım tasarımını açıklar. |
| Sequence Diagram | O | Bileşenler arasındaki mesajların zaman sırasını gösterir. |
| Component Diagram | O | Sistem bileşenleri ve bağımlılıklarını gösterir. |
| Deployment Diagram | O | Uygulama bileşenlerinin sunucu, container ve ağ üzerinde yerleşimini gösterir. |
| Data Flow Diagram | O | Verinin süreçler ve depolar arasındaki hareketini gösterir. |
| C4 Model | O | Sistemi context, container, component ve code seviyelerinde görselleştirme yaklaşımı. |
Bölüm uygulamaları
Bu bölümü bitirmeden önce şunları deneyin veya açıklayın.
- 20 sitelik multi-tenant commerce sistemi için tenant resolution, domain, database ve cache izolasyonunu tasarlayın.
- Monolith, modular monolith ve microservice seçeneklerini ekip büyüklüğü ve trafik açısından karşılaştırın.
- RTO/RPO hedefleriyle database backup, replica, failover ve restore drill planı oluşturun.