redis ile kafka arasındaki farklar

redis ile kafka’yı fintech tarafında kıyaslamak biraz veznedeki bozuk para çekmecesiyle bankanın arşiv odasını kıyaslamak gibidir.

ikisi de para işinin etrafında döner, ikisi de sistemin hızına etki eder, ikisi de yanlış kullanılırsa gece üçte insanı ayağa kaldırır. ama dertleri aynı değildir.

redis daha çok “şu an lazım olan bilgi” adamıdır.

müşteri oturum açmış mı?
otp kodu hâlâ geçerli mi?
kullanıcının son 1 dakikada kaç deneme hakkı kaldı?
fraud kontrolü için kısa süreli sayaç tutacak mıyız?
ödeme ekranında geçici işlem durumu gösterecek miyiz?

redis burada kraldır.

ram’de oturur, hızlı cevap verir, uzatmaz. ttl verirsin, süre dolunca veri gider. yani fintech sisteminde “bu bilgi lazım ama sonsuza kadar yaşamasın” dediğin yerde redis çok mantıklıdır.

mesela müşteri sms doğrulama kodu aldı. bu kodun 3 dakika geçerli olması gerekiyor. bunu gidip kafka’ya yazarsan olmaz mı? teknik olarak bin tane saçmalık yapılabilir ama doğru araç o değil. redis’e koyarsın, 180 saniye ttl verirsin, süre dolunca kod ölür. konu kapanır.

kvkk açısından da burada güzel bir taraf var: veri minimizasyonu ve saklama süresi disiplini. kişisel veriyi sırf “belki lazım olur” diye sistemin her yerine saçmamak gerekir. redis, doğru kullanılırsa kısa ömürlü, kontrollü ve geçici veri için gayet temiz bir alandır.

ama “doğru kullanılırsa” kısmı önemli.

çünkü redis’e tc kimlik no, kart verisi, müşteri adı soyadı, iban, telefon, ip, cihaz bilgisi ne bulduysan basıp sonra “nasıl olsa cache” demek, yazılımcı özgüveninin hukuki sonuç doğurmuş hâlidir. cache diye attığın veri de kişisel veridir. ram’de durması, günahını hafifletmez.

kafka ise başka bir hayvan.

kafka “şu anki değeri bana ver” sisteminden çok, “ne olduysa sırayla yaz, sonra isteyen okusun” kafasındadır. ödeme başlatıldı, risk kontrolüne gitti, fraud sistemi baktı, limit servisi onayladı, cüzdan bakiyesi güncellendi, bildirim gönderildi, muhasebe event’i üretildi… bunların hepsi event olarak akar.

fintech’te kafka genelde sistemler arası omurga olur.

ödeme akışı, para transferi, mutabakat, bildirim, fraud analizi, limit kontrolü, işlem geçmişi, raporlama, data pipeline… kafka burada “ben olan biteni sırayla yazarım, herkes de ihtiyacı olanı tüketir” der.

redis anlık refleks gibidir.
kafka olay hafızası gibidir.

redis’e “bu kullanıcı şu an login mi?” diye sorarsın.
kafka’ya “bu kullanıcının işlem yolculuğunda neler olmuş?” diye bakarsın.

redis hızdır.
kafka akıştır.

redis daha çok state tutar.
kafka event taşır.

redis veriyi genelde kısa yaşatır.
kafka veriyi retention politikasına göre günlerce, haftalarca, hatta aylarca saklayabilir.

işte kvkk tarafında kafka’nın ciddi düşünülmesi gereken yeri de burasıdır.

çünkü kafka’ya bir event attığında o event öyle “delete from kafam rahat” diye kolayca unutulan bir şey değildir. topic retention var, consumer lag var, replay var, backup var, log compaction var, downstream sistemlere dağılmış kopyalar var. bir de her mikroservis “ben de dinleyeyim” diye topic’e abone olduysa, kişisel veri mahalle çeşmesine dönmüş olabilir.

mesela şöyle bir event düşün:

“customer_payment_failed”

içinde ne var?

müşteri adı, telefon, iban, kartın ilk 6 son 4 hanesi, ip adresi, cihaz id, lokasyon, hata sebebi, işlem tutarı, merchant bilgisi…

sonra bu event kafka’ya atılıyor. fraud ekibi dinliyor. bildirim servisi dinliyor. raporlama dinliyor. data lake dinliyor. müşteri destek paneli dinliyor. bir de test ortamına replike ediliyor. sonra biri çıkıp “kvkk kapsamında bu veriyi silelim” deyince herkes kahvesini bırakıyor.

çünkü sorun artık sadece verinin bir yerde durması değil, verinin çoğalmasıdır.

fintech’te asıl mesele şudur: redis’e ne koyduğunu bilmek zorundasın, kafka’ya ne yaydığını iki kere bilmek zorundasın.

redis’te hata yaparsan genelde kısa süreli veri sızıntısı veya yanlış cache invalidation görürsün.
kafka’da hata yaparsan kişisel veriyi event mimarisinin damarlarına enjekte etmiş olursun.

bu yüzden kafka event tasarımında “ne lazım?” sorusu kadar “ne kesinlikle lazım değil?” sorusu da sorulmalı.

her event’e müşteri adı soyadı basılmaz.
her event’e telefon yazılmaz.
her event’e iban koyulmaz.
her event’e tc kimlik no hiç koyulmaz, aklı başında sistemde zaten konu oraya gelmez.

mümkünse customer_id gibi iç referans kullanılır.
ihtiyaç varsa maskeleme yapılır.
hassas veri tokenized edilir.
topic bazlı erişim sınırlandırılır.
retention süresi bilinçli belirlenir.
consumer’ların neyi nereye yazdığı takip edilir.
audit log tutulur ama audit log’un kendisi de veri çöplüğüne çevrilmez.

redis tarafında da aynı disiplin gerekir.

cache key isimlerinden bile veri sızabilir.
`user:905xxxxxxxxx:otp` gibi key yazarsan daha baştan kendini ele vermiş olursun.
daha temiz yaklaşım, anlamsız id veya hash tabanlı key kullanmaktır.
değer tarafında da ttl şarttır.
cache’e konan kişisel veri şifrelenmeli mi, maskelenmeli mi, hiç konmamalı mı; bu karar sistemin riskine göre verilmelidir.

fintech’te şöyle bir kaba ayrım yapılabilir:

redis:
anlık oturum, rate limit, otp, geçici işlem durumu, kısa süreli fraud sayaçları, idempotency lock, distributed lock, geçici token.

kafka:
ödeme event’leri, transfer akışı, fraud pipeline, mutabakat, asenkron bildirim, işlem durum değişiklikleri, audit’e gidecek teknik olaylar, data processing akışları.

ama kafka’yı audit log sanıp her şeyi içine boca etmek de yanlıştır. audit başka şeydir, event streaming başka şeydir. her event sonsuza kadar saklanacak belge değildir. her log da hukuki kanıt değildir.

kvkk açısından bakınca olayın özeti şudur:

kişisel veri hangi sistemde duruyor?
ne amaçla işleniyor?
ne kadar süre saklanıyor?
kim erişiyor?
hangi downstream sisteme gidiyor?
silme, maskeleme, anonimleştirme nasıl yapılacak?
veri ihlali olursa etki alanı neresi?

redis bu sorulara genelde daha kısa cevap verir.
kafka ise “otur kardeşim, mimari diyagramı açalım” dedirtir.

çünkü kafka olayların tren garıdır. bir event gelir, üç consumer alır, biri data lake’e yollar, biri elastic’e basar, biri müşteri destek ekranına taşır. sonra sen “şu kişisel veriyi kaldırdık mı?” diye sorduğunda konu sadece kafka topic’i olmaktan çıkar, tüm veri ekosistemine yayılır.

bu yüzden fintech’te redis kullanırken hız sarhoşu olmamak gerekir. kafka kullanırken de “event-driven architecture yaptık abi” diye kişisel veriyi konfeti gibi saçmamak gerekir.

redis iyi bir cache’tir, iyi bir kısa ömürlü state alanıdır, doğru yerde ilaçtır.
kafka iyi bir event omurgasıdır, doğru tasarlanırsa sistemin sinir ağıdır.

ama redis’e kalıcı hafıza muamelesi yaparsan üzülürsün.
kafka’ya geçici mesaj kuyruğu muamelesi yaparsan daha çok üzülürsün.
ikisinin üstüne kvkk’yı hiç düşünmeden fintech kurarsan zaten teknik borç değil, adli vaka biriktirirsin.

özetle:

redis hızlıdır, geçicidir, refleks verir.
kafka dayanıklıdır, sıralıdır, olayları taşır.
redis “şu an ne durumda?” sorusuna yakındır.
kafka “ne oldu, kim gördü, sonra nereye aktı?” sorusunu doğurur.

fintech’te ikisi de lazımdır.

ama kişisel veriyle çalışırken önemli olan hangi teknolojiyi seçtiğin değil, veriye ne kadar saygılı davrandığındır.

çünkü kvkk tarafında “abi o sadece cache’ti” ya da “abi o sadece event’ti” diye bir savunma yoktur.

kişisel veriyse kişisel veridir.
ram’de de dursa kişisel veridir.
topic’ten de aksa kişisel veridir.
log’a da düşse kişisel veridir.

teknoloji değişir, sorumluluk kalır.