Redis Pub/Sub mu, RabbitMQ mı? Hangisi Ne Zaman

Bir messaging layer seçimi çoğu zaman yıllarca sürer. Yanlış seçimi fark ettiğinizde taşınması pahalı olur. Bu yüzden başlangıçta bu kararı verirken doğru sorularla karar vermek önemli.

Bizim platformumuzda hem Redis Pub/Sub hem de RabbitMQ aktif. İkisi de gerekli. Bu yazıda kararı nasıl verdiğimizi, hangi senaryoda hangisini tercih ettiğimizi anlatacağım.

En baştan: ikisi de farklı problemleri çözüyor

Redis Pub/Sub ve RabbitMQ genelde aynı cümlede geçer ama çok farklı araçlardır.

Redis Pub/Sub — fire-and-forget broadcast. Mesaj yollarsın, o an dinleyen herkes alır. Dinlemeyenler mesajı kaybeder. Saklama yok, ack yok, retry yok.

RabbitMQ — kalıcı (veya yarı kalıcı) kuyruk. Mesajı kuyruğa koyarsın, consumer'lar sırayla alır, işler, ack'lar. İşlenmemiş mesaj kaybolmaz (kalıcı queue'larda).

Bu iki model aynı problem için alternatif değil — farklı problemler için tasarlanmış.

Ne zaman Redis Pub/Sub

Redis Pub/Sub için ideal senaryo:

• Bir oyun sunucusundan aynı anda oyundaki tüm oyunculara durum güncellemesi göndermek
• Bir canlı skor tahtasında skor değişikliklerini tüm bağlı clientlara push etmek
• Bir kullanıcı chat mesajı attığında, o chat odasındaki herkese iletmek
• Bir config değişikliği olduğunda tüm servislere "yeniden yükle" sinyali vermek

Ortak nokta: hızlı, geniş, kayıp tolere edilebilir. Oyunda bir pozisyon güncellemesi kaybolduysa bir sonraki geldiğinde yakalanır. Önemli olan hızlı yayılması, kayıpsız olması değil.

Latency: milisaniye altı. Bu, başka hiçbir broker'ın seviyesine yakın değil.

Ne zaman RabbitMQ

RabbitMQ için ideal senaryo:

• Bir siparişe ödeme bildirimi gönderme
• Turnuva sonucu hesaplanıp ödül dağıtılma
• Kullanıcı kayıt sonrası hoş geldin maili
• Analiz event'lerini veri ambarına gönderme

Ortak nokta: mesaj kaybı kabul edilemez, ama milisaniye önemli değil. Ödeme bildirimi 500ms gecikebilir, ama asla kaybolmamalı. Maili 2 saniye geç göndermek OK, hiç göndermemek sorun.

RabbitMQ burada ideal çünkü: mesaj persistence, ack/nack mekanizması, DLQ (dead letter queue), retry, routing. Bunlar iş kritik akışların temeli.

Kararda sorulacak 4 soru

Her yeni iş akışında kendime şunu soruyorum:

1. Bu mesajın kaybolması işi gerçekten kırar mı? Evet → RabbitMQ Hayır → Redis Pub/Sub

2. Yayının hızı yayının doğruluğundan önemli mi? Hız → Redis Doğruluk → RabbitMQ

3. Consumer offline olursa ne olmalı? "Dönünce devam etsin" → RabbitMQ "Kaçırdığı şeyleri unutabilirim" → Redis

4. Kaç tane consumer dinliyor? 1-3 → RabbitMQ genelde daha net 100-1000 → Redis Pub/Sub daha rahat ölçekleniyor

Gerçek senaryo: yanlış tercih yaptığımız ve bedelini ödediğimiz yer

Yıllar önce oyuncu bildirimleri için Redis Pub/Sub kullanmaya karar vermiştik. Mantık şöyleydi: "zaten Redis var, yeni bir altyapıya ihtiyaç yok, hızlı bildirim iyi."

3 ay sonra fark ettik: bir oyuncu offline'ken gönderilen bildirim kayboluyordu. Geri döndüğünde "kazandınız X TL" bildirimini hiç almıyordu. Kullanıcı desteği şikayetleri yükseldi.

Taşıma: 6 hafta. Yeni RabbitMQ kuyruğu, yeni consumer'lar, mevcut bildirim sistemi ile eski Redis sistemi arasında köprü. Hiç uğraşmak istemediğimiz bir iş.

Ders: persistence gerektiren her şey için Redis Pub/Sub kullanma. İşin başında bir dakika düşünmek sonraki altı haftayı kurtarır.

Peki ikisini de aynı platformda koşmak ne demek

Şu an bizde şu şekilde:

• Redis Pub/Sub — oyun odası içi state, lobby güncellemeleri, canlı skorlar, real-time metric fan-out
• RabbitMQ — ödeme olayları, turnuva sonucu, bildirim, e-posta, dış sistemlere event yayını

İki takım da kendi iş akışı için doğru aracı kullanıyor. Karışıklık yok, çünkü ilk günden "bu niye RabbitMQ, bu niye Redis" mantığını ekiple paylaştım.

Alternatif: Kafka?

Sorunuz olabilir: niye Kafka yok? Kafka harika bir araç ama bizim iş yüklerimizin çok büyük kısmı Kafka'nın güçlü olduğu alandan ayrı. Yüksek throughput mesaj akışımız (milyonlarca olay/saniye) yok. Event sourcing yok. Replay ihtiyacı nadir.

Kafka kurmak ve yönetmek bizim ihtiyacımız için ölçeksiz bir maliyet olurdu. RabbitMQ zaten yetiyor, Redis Pub/Sub zaten yetiyor, gerekli olmayan bir şey eklemedik.

Sonuç

Messaging layer seçiminde tek doğru cevap yok. Ama yanlış cevaplar var — ve bunlardan kaçınmanın yolu, her iş akışında dört soruyu sormaktan geçiyor. "Zaten kuruluydu, onu kullandık" cevabı genelde 6 ay sonra pişmanlıkla sonuçlanır.

İki aracı da tanıyın. İkisini de nerede kullanacağınızı anlayın. O zaman hangisi soru, hangisi cevap, rahatça görürsünüz.