Redis Pub/Sub Nedir? 30 Dakikada Gerçek Zamanlı Mimari

Meta Description

Redis Pub/Sub nedir? Gerçek zamanlı bildirim, chat ve event yayını için kanal yapısını öğrenin. 30 dakikada örnek kodla kurun.

Giriş (Introduction)

Gerçek zamanlı özellikler (bildirimler, canlı skor, chat, “sipariş hazır” güncellemeleri) kullanıcıyı elde tutar. Ama bu akışı sadece HTTP request/response ile kurmaya çalışınca sistem ya karmaşıklaşır ya da gereksiz polling yüzünden maliyet ve gecikme artar.

Redis Pub/Sub, uygulamalar arasında mesajları anlık yayınlamak için basit ama güçlü bir yöntemdir. “Bir olay oldu → ilgili servisler bunu hemen duysun” dediğiniz her yerde devreye girer.

Bu yazıda Redis Pub/Sub nedir sorusunu netleştirecek, ne zaman tercih etmeniz gerektiğini, sınırlamalarını, gerçek hayatta nasıl kurgulandığını ve 30 dakikada çalışan bir örneği adım adım göstereceğim.

Redis Pub/Sub Nedir?

Redis Pub/Sub, üreticinin (publisher) bir kanala mesaj yayınladığı ve tüketicilerin (subscriber) o kanala abone olup mesajları anlık aldığı bir mesajlaşma modelidir.

• Publisher: Mesajı yayınlar
• Channel: Mesajın “konusu” (ör. orders.status)
• Subscriber: Kanala abone olur, mesajı alır

Neden önemli?

• Düşük gecikme (low latency)
• Kurulumu kolay
• Geçici “event” akışları için hızlı çözüm

Kritik not: Redis Pub/Sub mesajları saklamaz. Abone o anda bağlı değilse mesajı kaçırır. Bu, onu “stream/queue” çözümlerinden ayırır.

Redis Pub/Sub ile Ne Çözersiniz? (Use-case’ler)

Aşağıdaki senaryolarda Redis Pub/Sub çok iş görür:

• Gerçek zamanlı bildirim: “Yeni yorum geldi”, “Sipariş kargoya verildi”
• Canlı dashboard: metrik, sayaç, anlık durum panoları
• Chat: odalara göre kanal mantığı (küçük/orta ölçek)
• Cache invalidation: bir servis cache’i güncelleyince diğerleri haberdar olsun
• WebSocket fan-out: Backend event’i yayınlar, gateway/ws sunucuları kullanıcılara iter

Gerçek hayattan örnek

E-ticarette “sipariş durumu” değiştiğinde:

• order-service durumu günceller
• PUBLISH orders.status {orderId, status}
• notification-service kullanıcıya push/e-posta tetikler
• websocket-gateway ilgili kullanıcı oturumuna anlık bildirimi yollar

Bu yaklaşım, servislerin birbirini doğrudan HTTP ile çağırma bağımlılığını azaltır.

Bunu Neden Yapmalıyım? (Redis Pub/Sub’un Avantajları)

Redis Pub/Sub tercih etmeniz için iyi nedenler:

1. Polling’i azaltır: İstemci 2 saniyede bir “durum değişti mi?” diye sormaz.
2. Servisleri gevşek bağlar (loose coupling): Publisher, subscriber’ı bilmez.
3. Uygulaması hızlıdır: Redis zaten çoğu sistemde cache için bulunur.
4. Performanslıdır: Basit iletim modeli sayesinde gecikme düşer.

Ne zaman kötü fikir?

• Mesaj kaybı kabul edilemiyorsa (ödeme, muhasebe, stok gibi)
• Tüketiciler zaman zaman offline oluyorsa ve “sonradan da işlemek” gerekiyorsa

Bu durumlarda Redis Streams, RabbitMQ veya Kafka gibi kalıcı çözümler daha uygundur.

Redis Pub/Sub Nasıl Çalışır? (Kısa Teknik Özet)

• Subscriber SUBSCRIBE channel ile bağlantıyı açar.
• Publisher PUBLISH channel message ile mesaj gönderir.
• Redis, o an bağlı tüm subscriber’lara mesajı iletir.

Kanal isimlendirme önerisi

Anlaşılır bir sözleşme (contract) belirleyin:

• orders.status
• orders.created
• notifications.user.{userId}
• chat.room.{roomId}

Kanallar için versioning düşünün: orders.status.v1 gibi. İleride payload değişince kırılma azalır.

30 Dakikada Uygulama: Node.js ile Publish/Subscribe

Aşağıdaki örnek, iki ayrı process ile çalışır:

• subscriber.js kanalı dinler
• publisher.js mesaj yollar

1) Redis’i çalıştırın (Docker)

docker run --name redis -p 6379:6379 -d redis:7

2) Projeyi hazırlayın

mkdir redis-pubsub-demo && cd redis-pubsub-demo
npm init -y
npm i redis

3) Subscriber (dinleyici)

subscriber.js

import { createClient } from "redis";

const client = createClient({ url: "redis://localhost:6379" });
client.on("error", (err) => console.error("Redis error:", err));

await client.connect();

const channel = "orders.status.v1";
console.log("Subscribed to:", channel);

await client.subscribe(channel, (message) => {
  // Mesaj string gelir; genelde JSON kullanılır
  const data = JSON.parse(message);
  console.log("Event:", data);
});

4) Publisher (gönderici)

publisher.js

import { createClient } from "redis";

const client = createClient({ url: "redis://localhost:6379" });
client.on("error", (err) => console.error("Redis error:", err));

await client.connect();

const channel = "orders.status.v1";
const payload = {
  orderId: "ORD-1042",
  status: "SHIPPED",
  updatedAt: new Date().toISOString()
};

const receivers = await client.publish(channel, JSON.stringify(payload));
console.log(`Published. Receivers: ${receivers}`);

await client.quit();

5) Çalıştırın

Terminal-1:

node subscriber.js

Terminal-2:

node publisher.js

Subscriber tarafında event’i anında görmelisiniz.

Üretimde Dikkat Edilecekler: Güvenilirlik, Ölçek, Güvenlik

Redis Pub/Sub kolaydır ama üretimde bazı noktalar kritik.

1) Mesaj kaybı gerçeğini kabul edin

Redis Pub/Sub mesaj saklamaz. Aşağıdaki tablo karar vermeyi kolaylaştırır:

2) Payload tasarımı

Mesajı JSON gönderecekseniz şunları eklemek iyi pratik:

• eventId (idempotency / debug)
• eventType (ör. OrderStatusChanged)
• occurredAt
• version

3) Backpressure yok: tüketici yavaşsa ne olur?

Pub/Sub tarafında kuyruk olmadığı için, yavaş tüketiciler sorun çıkarabilir.

• Mesajları küçük tutun
• Subscriber’da işi hızlı yapın (gerekirse işi kuyruk/worker’a devredin)

4) Ölçekleme

Birden fazla subscriber instance’ı olabilir; hepsi aynı kanalı dinliyorsa hepsi mesajı alır.

• “Herkese yayın” istiyorsanız bu iyidir.
• “İş paylaşımı (work queue)” istiyorsanız Pub/Sub doğru araç değildir.

5) Güvenlik

• Redis’i internete açık bırakmayın
• ACL/şifre kullanın
• TLS gerekiyorsa managed Redis tercih edin

Yaygın Hatalar (ve Hızlı Çözümler)

• Hata: Pub/Sub’u “event log” gibi kullanmak
  • Çözüm: Kalıcı ihtiyaç varsa Streams/queue
• Hata: Tek kanal altında her şeyi yayınlamak (events)
  • Çözüm: Alan bazlı kanal tasarımı (orders.*, payments.*)
• Hata: Mesajları çok büyük göndermek
  • Çözüm: Mesajda sadece referans (ID) yolla, detayları gerektiğinde çek

Sık Sorulan Sorular (FAQ)

1) Redis Pub/Sub ile Redis Streams arasındaki fark nedir?

Pub/Sub mesajları saklamaz ve bağlı olmayan subscriber mesajı kaçırır. Streams mesajları kalıcı tutar, consumer group ile sonradan da işlenebilir.

2) Redis Pub/Sub ile job queue yapılır mı?

Teknik olarak yapılabilir ama doğru yaklaşım değildir. İş paylaşımı ve yeniden deneme (retry) için queue/streams daha uygundur.

3) Pub/Sub WebSocket yerine geçer mi?

Hayır. Pub/Sub sunucular arası mesajlaşmadır. WebSocket ise istemciye sürekli bağlantı sağlar. Pratikte Pub/Sub, WebSocket gateway’lerini beslemek için kullanılır.

4) Mesajlar sıralı gelir mi?

Tek bir bağlantı ve tek bir channel akışında genelde sıralı gözlemlenir; ancak dağıtık sistem koşullarında “tam sıralama garantisi” varsayımı risklidir. Kritik işlerde kalıcı ve sıralama garantili sistemler tercih edin.

Sonuç

Redis Pub/Sub, gerçek zamanlı event yayını için hızlı ve etkili bir çözümdür: bildirim, canlı dashboard, chat gibi senaryolarda polling’i azaltır ve mimariyi sadeleştirir. Ancak mesaj kaybı kabul edilemeyen süreçlerde Pub/Sub yerine kalıcı mesajlaşma seçeneklerine yönelmek gerekir.

Bir sonraki adım olarak kendi projenizde bir kanal sözleşmesi belirleyip (ör. orders.status.v1) küçük bir “status changed” event’i yayınlamayı deneyin. Takıldığınız noktayı yorum olarak yazın; örneğin kanal tasarımınızı veya payload formatınızı birlikte iyileştirebiliriz.