Redis Pub/Sub vs Kafka: Backend Eventing Icin Hangi Model Ne Zaman?

Backend sistemlerde ekipler genellikle su soruyla karsilasir: "Bu olayi Redis Pub/Sub ile mi dagitalim, yoksa dogrudan Kafka mi kullanalim?" Iki teknoloji de pub/sub modeli sunar gibi gorunse de calisma sekilleri, hata toleransi ve operasyonel davranislari oldukca farklidir. Yanlis tercih, kisa vadede hizli gelisse bile uzun vadede veri kaybi, yeniden oynatma ihtiyaci ve gozlemlenebilirlik sorunlari dogurur.

Bu yazinin hedefi "hangisi daha iyi" demekten cok, "hangi ihtiyac icin hangisi dogru" sorusuna teknik bir karar cercevesi sunmak. Ozellikle teslimat garantisi, siparis (ordering), gecikme, geri basinclama (backpressure), tekrar oynatma (replay) ve maliyet boyutlarini birlikte ele alacagiz.

Problem tanimi: Event dagitimi ayni sey degildir

Uretimde event dagitimi yaparken tum akislar ayni profile sahip olmaz:

• Bazi eventler anliktir ve kayboldugunda sistem icin kritik degildir (or. canli dashboard metrik pingi).
• Bazilari ise is kurallari acisindan kritiktir (or. "odeme alindi", "fatura kesildi", "stok azaldi").
• Bazi tuketiciler gecici olarak offline olabilir; sonra kacirdigi olaylari telafi etmesi gerekir.

Redis Pub/Sub bu tabloda "anlik yayin" tarafinda cok gucludur: yayinci mesaji yollar, o anda abone olanlar alir. Ancak abone kapaliysa mesaji kacirir. Kafka ise "kalici log" tarafinda gucludur: olaylar topic-partition icinde saklanir, consumer gruplari offset takip ederek gecmise donup replay yapabilir.

Mimari farklar: Ephemeral kanal vs kalici event log

Redis Pub/Sub

• Mesajlar memory odakli ve gecicidir.
• Broker mesaji push eder, teslimat gecmisi tutmaz.
• Basit kanal semantigi vardir, kurulum ve baslangic maliyeti dusuktur.
• Milisaniye seviyesinde dusuk gecikme isteyen bildirim tiplerinde etkilidir.

Kafka

• Olaylar disk uzerinde kalici log olarak tutulur.
• Consumer offset yonetimi sayesinde "nereye kadar okudum?" bilgisi vardir.
• Replay, reprocessing, gec gelen tuketiciler ve audit ihtiyaci icin dogal cozum sunar.
• Partition modeli yuksek throughput ve paralel tuketim saglar; fakat dogru partition key secimi kritik onemdedir.

Bu nedenle karar verirken ilk soru teknoloji degil, veri kaybi toleransi olmalidir: "Bir consumer 10 dakika dusse ne olur?" Eger cevap "hicbir sey olmamali, tum olaylari sonradan da isleyebilmeli" ise Kafka guclu adaydir.

Teslimat garantileri ve siparis (ordering) trade-off'lari

Redis Pub/Sub tarafinda klasik model "best effort"tur. Ag kopmasi, consumer restart'i veya deployment penceresinde mesaj kaybi riski vardir. Bunun yerine Redis Streams gibi yapilar kullanilarak dayaniklilik artirilabilir; fakat bu artik klasik Pub/Sub'tan farkli bir modeldir.

Kafka tarafinda at-least-once davranisi standarttir. Dogru producer ayarlari (acks=all, idempotent producer) ve consumer commit stratejisi ile kopya mesaj ihtimali yonetilebilir. Tam "exactly-once" pratikte her zaman uygulama sinirlariyla birlikte dusunulmelidir; cunku veritabani yazimi, dis servis cagri ve side-effect yonetimi de denkleme girer.

Siparis konusunda da benzer nuance vardir:

• Kafka global siralama garanti etmez, partition icinde siralama garanti eder.
• Redis Pub/Sub tarafinda daginik subscriber davranisi ve yeniden baglanma senaryolari global siralamayi zorlastirir.

Eger "bir kullanicinin olaylari kendi icinde sirali olmali" gibi ihtiyac varsa, Kafka'da partition key olarak userId secmek daha ongorulebilir sonuc verir.

Uygulama akislari: Hangi senaryoda hangisi?

Redis Pub/Sub'a uygun senaryolar

1. Gercek zamanli ama kayba toleransli bildirimler (or. "yeni yorum geldi" toast bildirimi).
2. Kisa omurlu websocket fan-out akislari.
3. Sistem ici "hizli sinyal" mekanizmalari (cache invalidation trigger gibi) ve gerekirse fallback mekanizmasi olan durumlar.

Kafka'ya uygun senaryolar

1. Islemsel olaylarin sonradan denetlenmesi gereken sistemler (odeme, siparis, faturalama).
2. Coklu consumer grubunun ayni olayi farkli amaclarla islemesi (analytics, fraud, notification, reporting).
3. Yeni bir servisin gecmis olaylari replay ederek hizlica ayaaga kalkmasi gereken event-driven mimariler.

Karma bir mimari da sik kullanilir: Kaynak servis olayi once "guvenilir kanal" olarak Kafka'ya yazar, kullaniciya anlik hissettirmek icin bazi turev sinyalleri Redis uzerinden gecer. Bu model, hiz ve dayaniklilik dengesini pratikte iyilestirir.

Hata senaryolari ve anti-patternler

En sik yapilan hata, Redis Pub/Sub ile kritik domain event tasimaktir. Sistem bir sure "calisiyor gibi" gorunur, fakat ilk buyuk deploy veya ag dalgalanmasinda kayip olaylar ortaya cikar. Bu durum genellikle veri tutarsizligi olarak geri doner.

Diger bir anti-pattern, Kafka kullanirken tum olaylari tek partition'a yigip hem throughput'u dusurmek hem de consumer lag'i buyutmektir. Partition key tasarimi is yukune gore yapilmali; "hot key" olusturacak secimlerden kacinilmalidir.

Ayrica asagidaki kontroller atlanmamalidir:

• Producer retry ve timeout politikalari net degilse duplicate veya kayip etkisi buyur.
• Consumer idempotency yoksa replay sonrasi ayni is iki kez islenir.
• Dead-letter topic/queue tanimi yoksa zehirli mesaj tum akis hattini tikar.

Olcumleme ve gozlemlenebilirlik

Kararin dogru olup olmadigini metriklerle anlarsiniz. Izlenmesi gereken temel gostergeler:

• End-to-end event latency (publish -> consume -> side effect tamamlanma suresi)
• Consumer lag (Kafka icin partition bazli)
• Retry/failed consume oranlari
• Dead-letter hacmi ve tekrar isleme basari orani
• Mesaj boyutu dagilimi ve throughput trendleri

Redis odakli akislarda subscriber disconnect orani ve reconnect sonrasi kayip etkisi ayrica raporlanmalidir. Kafka tarafinda ise lag alarmi sadece threshold ile degil, lag artis hiziyla birlikte izlenmelidir.

Uretime alma kontrol listesi

• Event siniflarini "kritik" ve "anlik" olarak ayirin.
• Kritik olaylar icin kalici log/replay ihtiyacini netlestirin.
• Producer ve consumer idempotency stratejisini dokumante edin.
• Topic/channel isimlendirme standardi belirleyin.
• Backpressure politikasini (drop, queue, degrade) acikca yazin.
• SLO tanimlayin: p95 latency, veri kaybi toleransi, max lag.
• Olay semasi degisiklikleri icin versiyonlama kurali koyun.

Sonuc olarak Redis Pub/Sub ve Kafka rakip olmaktan cok farkli problem siniflarini cozer. "Dusuk gecikmeli anlik sinyal" icin Redis Pub/Sub son derece pratiktir; "kalici, denetlenebilir, replay edilebilir event omurgasi" icin Kafka daha guvenli bir zemindir. Mimari olgunlastikca ikisini birlikte kullanmak da son derece dogal bir tercih haline gelir.