Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124

Bu yazıda, sistem tasarımında çok kritik bir kavram olan message queue (mesaj kuyruğu) mantığını gerçekten anlayacaksın. Sadece tanım değil, neden kullanılır, hangi problemi çözer ve gerçek sistemlerde nasıl iş görür, hepsini net şekilde kavrayacaksın.
Şimdi şöyle bir düşün…
Bir pizza dükkanına girdin. Sipariş verdin. Ama sana pizza hemen verilmiyor. Onun yerine:
“Siparişin alındı, biraz bekle” deniyor
Aslında burada çok kritik bir şey oluyor.
Yani şöyle düşün:
Sistem sana sonucu hemen vermek zorunda değil
Sadece “işin sıraya alındı” bilgisini veriyor
Sen beklerken başka iş yapabiliyorsun.
Telefonuna bakıyorsun, dışarı çıkıyorsun vs.
Bu ne demek biliyor musun?
Sistem seni bloklamıyor (bekletmiyor)
Pizza dükkanında bir liste var:
Ve bu liste sırayla işleniyor.
Bu aslında tam olarak bir queue (kuyruk).
Kasada sipariş alınıyor → mutfakta sırayla hazırlanıyor
Önemli nokta şu:
Sipariş almaya devam ediyorsun
Ama işlemleri sırayla yapıyorsun
Bu sayede sistem hem hızlı hissediliyor hem de kontrol edilebilir oluyor.
Şimdi biraz daha ileri gidelim.
Her sipariş aynı değil:
Bu durumda ne yaparsın?
Öncelik verirsin
Kuyruk var ama bazı işler “öne alınabiliyor”
Yani sistem sadece sıraya göre değil, öneme göre de karar verebiliyor.
Şimdi iş büyüdü diyelim…
Artık tek pizza dükkanı yok. 3 tane şube var.
Ama bir problem çıktı:
Şubelerden biri çöktü (örneğin elektrik gitti)
Peki o şubedeki siparişler ne olacak?
Eğer siparişler sadece RAM’de tutuluyorsa:
Sistem kapanınca her şey gider
Bu yüzden ne gerekir?
Database (veritabanı)
Siparişler sadece akılda değil, deftere de yazılıyor
Böylece:
Diyelim ki bir sunucu çöktü.
O sunucuda işlenen siparişler:
Yarım kaldı
Bu durumda sistem ne yapmalı?
Bu işleri başka sunuculara vermeli
Ama burada bir risk var:
Şimdi kritik noktaya geldik.
Diyelim ki bir sipariş zaten işleniyordu ama:
Sonuç?
❌ Aynı pizza iki kere yapıldı
❌ Maliyet + karışıklık
Bu problemi çözmek için kullanılan tekniklerden biri:
Load Balancing
Ama sadece yük dağıtmak değil…
Aynı işi tekrar göndermemek de önemli
Burada devreye giriyor:
Consistent Hashing
Her sunucunun kendine ait bir “iş alanı” var
Bir sunucu giderse → sadece küçük bir kısmı diğerlerine dağıtılıyor
Yani tüm sistem yeniden karışmıyor.
Peki sistem bir sunucunun öldüğünü nasıl anlıyor?
Heartbeat (nabız kontrolü) ile
Sistem her 15 saniyede bir “yaşıyor musun?” diye soruyor
Cevap yoksa → “öldü” kabul ediyor
Sonra ne yapıyor?
O sunucunun işlerini alıp diğerlerine dağıtıyor
Buraya kadar fark etmişsindir…
Bunların hepsini tek tek yazmak:
Aşırı kompleks
İşte burada devreye giriyor:
İşleri alır
Saklar
Doğru sunucuya verir
Tamamlanana kadar takip eder
Eğer bir sunucu cevap vermezse:
İşi başka sunucuya verir
Yani tüm karmaşıklığı kapsüller.
Bu mantığı implement eden sistemler var:
Bunlar sana şunu sağlar:
Komple sistemi sıfırdan yazmana gerek kalmaz
Aslında tüm olay şuna dayanıyor:
Bir sistemi daha ölçeklenebilir, daha dayanıklı ve daha hızlı hissettirmek istiyorsan, işleri doğrudan yapmak yerine sıraya alman gerekiyor. Mesaj kuyrukları tam olarak bunu yapıyor. Kullanıcıyı bekletmeden işi sıraya koyuyor, arka planda işliyor, hata olursa yeniden deniyor ve sistemi çökse bile ayakta tutuyor. Büyük sistemlerin çoğunda bu yüzden message queue görmek çok normal.
Bu yazı What is a MESSAGE QUEUE and Where is it used? videosundan ilham alınarak yazılmıştır.



