Referans Mimari: 3-katmanlı OLTP uygulaması
Klasik iş uygulamaları (sipariş, ödeme, envanter) çok sayıda kısa, tekil ve tutarlılık gerektiren işlem yürütür (OLTP). Bu ağaç; yük profilini belirlemekten başlayarak birincil ilişkisel veritabanı seçimi, bağlantı havuzu (connection pooler), okuma replikası, önbellek katmanı, yedekleme + PITR ve izleme bileşenlerinin ne zaman devreye alınacağını adım adım gösterir. Amaç 'her şeyi baştan koymak' değil, darboğaz kanıtlandıkça doğru bileşeni eklemektir.
Yük profilin nasıl: işlem karışımı ve tutarlılık ihtiyacı ne?
OLTP mimarisinde ilk karar, iş yükünün gerçekten işlemsel (kısa, ACID gerektiren yazma/okuma karışımı) olup olmadığıdır. Verinin doğal olarak ilişkisel ve tutarlılık kritik mi (para, stok, sipariş), yoksa ağırlıklı okuma mı yapılıyor, ya da henüz yük çok mu düşük?
- Kısa işlemler, güçlü tutarlılık (para/stok/sipariş)
- Okuma çok baskın, yazma az ve trafik yükseliyor
- Yük çok düşük; en sade kurulum yeterli mi?
Birincil veritabanı motorunu seçtin mi, ölçek endişen var mı?
İşlemsel çekirdek için ilişkisel bir motor doğru temeldir (PostgreSQL, MySQL/InnoDB, Oracle, SQL Server). Motor seçimi netse sıradaki soru ölçeklemedir: tek örnek şu an yetiyor mu, yoksa bağlantı sayısı ve okuma yükü artıyor mu?
- Motor net; şimdilik tek örnek yetiyor
- Bağlantı sayısı çok yükseldi, kaynak tükeniyor
- Okuma yükü büyüyor, yazma ana örneği zorluyor
Okumaları nasıl ölçekleyeceksin: replika mı, önbellek mi?
Okuma yükü ana örneği zorluyorsa iki tamamlayıcı seçenek var. Raporlama/liste gibi biraz gecikmeli veriyi tolere edebilen okumalar bir okuma replikasına yönlendirilebilir; aynı 'sıcak' veriler defalarca isteniyorsa mikrosaniye gecikmeli bir önbellek (Redis) DB'yi rahatlatır.
- Rapor/liste okumaları çok; hafif gecikme kabul
- Aynı popüler veriler tekrar tekrar okunuyor
Öneri: Tek primary + havuz + yedek ile başla
Erken aşamada mimariyi basit tut: tek bir ilişkisel primary örnek, önünde bir bağlantı havuzu ve düzenli yedek yeterlidir. Karmaşıklığı ancak ölçülen bir darboğaz zorlayınca ekle.
Öneri: Bağlantı havuzu (connection pooler) ekle
OLTP'de her uygulama örneği kendi bağlantılarını açtığında, primary DB binlerce bağlantı altında bellek ve zamanlayıcı yükünden boğulur. Araya bir havuz koyarak az sayıda gerçek DB bağlantısı çok sayıda uygulama isteğine paylaştırılır.
Öneri: Okuma replikası (read replica) ekle
Yazma primary örnekte kalırken, primary'den akan bir veya daha fazla asenkron replikaya salt-okuma trafiği (rapor, liste, arama) yönlendirilir. Böylece primary, yazma ve tutarlılık kritik okumalar için serbest kalır.
Öneri: Önbellek katmanı (Redis) ekle
Aynı popüler veriler (oturum, katalog, profil, sayfa parçaları) defalarca okunuyorsa, DB'nin önüne bir bellek-içi önbellek koyup okumaların çoğunu DB'ye hiç ulaştırmadan karşılarsın. Gecikme düşer, primary DB rahatlar.