• 07-07-2026, 20:36:14
    #1
    Selamlar,

    Aklıma takılan bir konu var.

    Diyelim ki saniyede 100.000 istek alıyorsunuz ve bunların tamamı gerçek kullanıcı istekleri. Mevcut sunucunuz bu yükü kaldırabiliyor ancak daha küçük sunucular kullanmak istediğiniz için size bir load balancer kullanmanız öneriliyor.

    Benim merak ettiğim nokta şu:

    Load balancer, gelen istekleri farklı uygulama sunucularına dağıtıyor. Ancak bu 100.000 isteğin tamamının veritabanına erişmesi gerektiğini varsayalım. Tüm uygulama sunucuları da ortak olarak aynı veritabanını kullanıyor.

    Bu durumda load balancer'ın sağladığı avantaj tam olarak nedir?

    Sonuçta bütün istekler yine aynı veritabanına gidecek. Eğer darboğaz veritabanındaysa, uygulama sunucularını çoğaltmanın performansa nasıl bir katkısı oluyor? Yoksa bu senaryoda asıl darboğaz veritabanı olacağı için load balancer tek başına bir çözüm sağlamıyor mu?

    Bu mimaride mantığını kaçırdığım nokta nedir?
  • 07-07-2026, 20:39:14
    #2
    Cache sistemini düzgün kurduktan sonra veritabanı işlemlerini de bu ölçüde kısmış olacaksınız zaten hocam.
  • 07-07-2026, 20:41:25
    #3
    Genelde her istek DB’ye gitmez, cache kullanılır o yüzden LB işe yarar. Veritabanı tarafında da çok yük oluştuğu zaman read-only replicalar ile scale edilir.
  • 07-07-2026, 20:43:50
    #4
    BySocial adlı üyeden alıntı: mesajı görüntüle
    Cache sistemini düzgün kurduktan sonra veritabanı işlemlerini de bu ölçüde kısmış olacaksınız zaten hocam.
    Django adlı üyeden alıntı: mesajı görüntüle
    Genelde her istek DB’ye gitmez, cache kullanılır o yüzden LB işe yarar. Veritabanı tarafında da çok yük oluştuğu zaman read-only replicalar ile scale edilir.
    Burada aslında "Database gerektiren işlem" olarak belirtmemin sebebi şuydu; Redis sistemi var aslında saniyede 100k create order isteği geliyor ve saniyede 100k veriyi kesinlikle write etmeliyiz olarak sormak istedim.
    Buradaki asıl sorum; "Ortak database sistemi nasıl çalışiyor?" Mantığını anlamak adına sordum.
  • 07-07-2026, 20:45:37
    #5
    çok farklı yöntemler var.
    bunu yapmıştık aws üzerinde sırası ile yaptıklarımız.
    global accelerator
    application lb
    auto scaling.
    fakat öncesinde web server optimizasyonlar cache sistemi gerekli yerde in memory db kullanmıştık.

    fakat bu tamamen projeye göre değişecek şeylerdir biz blokchain alt yapısında kullanmıştık bunları.
  • 07-07-2026, 20:45:46
    #6
    Güzel konu. Gün gelir bana lazım olur. O yüzden favoriledim. Teşekkürler.
  • 07-07-2026, 20:48:43
    #7
    ByTriSLaSiS adlı üyeden alıntı: mesajı görüntüle
    çok farklı yöntemler var.
    bunu yapmıştık aws üzerinde sırası ile yaptıklarımız.
    global accelerator
    application lb
    auto scaling.
    fakat öncesinde web server optimizasyonlar cache sistemi gerekli yerde in memory db kullanmıştık.

    fakat bu tamamen projeye göre değişecek şeylerdir biz blokchain alt yapısında kullanmıştık bunları.
    Öncelikle teşekkür ediyorum.
    Şöyle bir soru sormak istiyorum şimdi 1 sunucu(8gb ram) 50k Create order isteğini database de anlık olarak işleyebiliyoruz diyelim. Ve 100k istek alıyorsam 1 tane daha 8 gb ramli sunucu alayım 2 sunucu eş zamanlı kullanayim istiyorum.
    Araya da bir tane VDS alıp Loadbalancer yapıp hangi VDSe aktarilsin onu ayarlayayim istiyorum. Ama şimdi create order geldiğinde hem 1. VDS hemde 2. VDS eş zamanlı nasıl senkronize olacak?
  • 07-07-2026, 20:56:50
    #8
    soylenmezsmt adlı üyeden alıntı: mesajı görüntüle
    Öncelikle teşekkür ediyorum.
    Şöyle bir soru sormak istiyorum şimdi 1 sunucu(8gb ram) 50k Create order isteğini database de anlık olarak işleyebiliyoruz diyelim. Ve 100k istek alıyorsam 1 tane daha 8 gb ramli sunucu alayım 2 sunucu eş zamanlı kullanayim istiyorum.
    Araya da bir tane VDS alıp Loadbalancer yapıp hangi VDSe aktarilsin onu ayarlayayim istiyorum. Ama şimdi create order geldiğinde hem 1. VDS hemde 2. VDS eş zamanlı nasıl senkronize olacak?
    Google cloud postgresql kullanmıştık bunun adı google cloudda farklı idi sanırım alloydb idi bu süreçleri cloud tarafında aws ve google otomatik yönetiyor fakat eskiden cluster mantığı ile yapıyorduk.
    bu gibi durumları şuan yaşıyorsanız hızlı aksiyon almanız gerekebilir fakat gelecek için düşünüyorsanız şimdiden düşünmeyin; zaman ve tecrübe zaten sizi bu sürece hazırlıyor; hazırlayacaktır.
    fakat ben merak ediyorum diyorsanız;

    alloydb tarafında bir adet node kaldırdık ayağa; otomatik süreci yönetmedi fakat sanırım hihg avalibity vardı fail over esnasında araya giriyordu zaten bu servislerde aslında çift katmana gerek yok bir çok şeyi yönetiyor.
    mysql tarafında bir kaç seçenk var partition sistemi vardı eskiden ilk başvurduğum noktaydı.
    sonra mgp keşfettim innodb cluster sistemi burada çakışmalarda sorun yaşamıştık.
    mariadb persona var birde isimlerde hata yapabilirim bakmanızda fayda var eş zamanlı senkron çalışan buydu sanırım.
    bugüne kadar bir çok yapıda çalışma şansım oldu fakat tam olarak projenize göre siz değerlendirmelisiniz.
    aslında bir proxmox kurun vm'ler oluşturup testlerinizi kendiniz yapmanız sanırım daha sağlıklı olur.
    yani daha iyi bilen arkadaşlar umarım yazarlar bizde bilgi edinmiş oluruz.
    güzel bir konu.