Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Modern dijital ürünlerin arkasında saniyede yüz binlerce olayı yöneten görünmez bir omurga var. LinkedIn, Netflix, Uber gibi devlerin ortak noktası ise bu trafiği Apache Kafka ile yönetiyor olmaları. Peki Kafka’yı bu kadar özel yapan ne? Yalnızca ölçeklenebilir olması mı, yoksa mimaride sunduğu başka avantajlar mı var?
Bu yazıda Kafka’nın mimarisini, sunduğu faydaları, ölçeklenme stratejilerini ve dikkat edilmesi gereken noktaları profesyonel bir perspektifle ele alıyoruz.
✔️ Kafka Nedir? Neden Kullanılıyor?
Kafka’yı şöyle düşünebilirsin:
- Sistemler arasında mesaj taşıyan çok hızlı bir kargo şirketi gibi.
- Bir servis bir olay üretir (örneğin: “kullanıcı giriş yaptı”), Kafka bunu alır ve başka servislere iletir.
- Servisler birbirine doğrudan bağlı olmaz → böylece bir servis çökerse diğeri etkilenmez.
- Trafik bir anda artarsa Kafka bunu buffer’lar, yani geçici olarak depolar.
- Geçmişteki olayları tekrar oynatabildiği için (replay), hata ayıklama çok kolaydır.
- En büyük özelliği: aşırı yüksek hız. Saniyede yüz binlerce mesaj işleyebilir.
Kısacası:
“Sistemdeki tüm olayların geçtiği, çok hızlı çalışan bir kayıt defteri + dağıtım hattı” gibi düşünebilirsin.
✔️ Kafka’nın Mimarisinin Temeli: Topic & Partition
📌 Topic
Topic, Kafka’da “kategori” demek.
Örneğin:
orderspaymentsuser-login-events
Tüm mesajlar bir topic altında toplanır.
📌 Partition
Her topic’in içinde 1 veya daha fazla partition olur. Partition’ı şöyle hayal et:
Disk üzerinde ardışık şekilde yazılan bir günlük (log) dosyası.
Append-only → sadece sona eklenir, silme yok.
📌 Peki partition neden önemli?
Çünkü Kafka’nın performansının kalbi burasıdır.
- Her partition bağımsızdır.
- 1 partition → 1 işlem hattı
- 10 partition → 10 paralel işlem hattı
- Partition sayısı arttıkça paralellik artar → throughput artar.
Basit örnek:
Tek kasa olan market kuyruk oluşturur.
10 kasa açınca herkes hızlı geçer.
Kafka’daki her partition = bir kasa.
✔️ 2. Broker ve Cluster: Yatay Ölçeklenme Nedir?
Kafka tek bir makinede çalışmaz; genelde birden fazla sunucunun (broker) bir araya gelmesiyle çalışır.
Bu sunucular birleşince cluster oluşur.
Bunu şöyle düşün:
- Tek bir kamyonla tüm şehre kargo dağıtamazsın → yavaşlar.
- Ama 10 kamyonun varsa → her biri ayrı bölgeye gider, hız artar.
Kafka’da da aynı mantık var:
- Her broker kendi başına saniyede yüz binlerce mesaj taşıyabilir.
- Broker sayısını artırdıkça sistem yanlamasına büyür (yatay ölçeklenme).
📌 Kafka neden hızlı?
- Kafka genelde CPU’dan değil network’ten boğulur.
Yani işlemci yerine gelen-giden trafik sınırlayıcı olur. - Disk yazması çok hızlıdır çünkü Kafka diske sıralı (sequential) şekilde yazar.
Rastgele yazma değil → aynı hattan akıyor → çok hızlı.
✔️ 3. Message Key ve Sıralama Mantığı
Kafka’ya gönderilen her mesaj aslında küçük bir paket gibidir. İçinde genelde şunlar olur:
- Key → Mesajı gruplayan değer
- Value → Asıl veri
- Timestamp → Zaman bilgisi
- Header → Ek bilgiler (opsiyonel)
📌 Peki Kafka mesajların sırasını nasıl koruyor?
Şöyle:
- Eğer mesajların key değeri aynıysa, Kafka bunları her zaman aynı partition’a gönderir.
- Bu sayede sıra bozulmaz.
Çünkü bir partition içindeki mesajlar her zaman ilk giren ilk çıkar mantığıyla ilerler.
Örnek:userId = 42 olan bir kullanıcının tüm işlemleri hep aynı partition’a gider.
Böylece olay akışı sırasını kaybetmezsin.
📌 Key vermezsen ne olur?
Kafka der ki:
“Tamam, o zaman ben mesajları partition’lar arasında kendim eşit şekilde dağıtayım.”
Bu da yük dengesi sağlar ama sıra garantisi olmaz.
✔️ Partitioning Stratejisi: Doğru Key Sistemi Kurtarır
Kafka’nın yüksek performanslı çalışıp çalışmaması çoğu zaman hangi key’i seçtiğine bağlıdır.
Key doğru seçilirse trafik eşit dağılır → sistem rahatlar.
Key yanlış seçilirse tüm yük tek bir noktaya yığılır → sistem boğulur.
❌ Yanlış Key Seçimi: Hot Partition Sorunu
Hot partition şudur:
- Tüm trafik tek bir partition’a akıyorsa, orası aşırı ısınır.
- Bu da “boğazın tıkanması” gibi sistemi yavaşlatır.
📌 Örnek (çok anlaşılır):
Bir video platformu düşün (Netflix gibi).
Sen partition key olarak movieId seçtin.
Cuma akşamı yeni bir film çıktı → milyonlarca kişi aynı filmi açtı.
Ne olur?
- Tüm event’ler aynı movieId’ye sahip.
- Hepsi tek partition’a gidiyor.
- O partition nefes alamıyor.
- Kafka’nın paralelliği çöker → sistem yavaşlar.
İşte buna hot partition deniyor.
✔️ Doğru Çözüm: Compound Key Kullanmak
Bu problemi çözmek için key’i biraz daha akıllı yaparız.
📌 Çözüm:
movieId + hash(userId)
(İkisini birlikte kullanıyorsun)
Bu ne sağlar?
🎉 1. Trafik Çoklu Partition’a Dağılır
Aynı film izleniyor olsa bile:
- Kullanıcılar farklı olduğundan
- “hash(userId)” değeri sayesinde
- Mesajlar farklı partition’lara gider.
Yani yük eşit bölünür → sistem rahatlar.
🎉 2. Tek Kullanıcının Event Sırası Bozulmaz
İster 100 milyon kişi aynı filmi açsın:
- Bir kullanıcının tüm event’leri yine aynı partition’a gider.
- Çünkü key içindeki userId hep aynı.
Bu da o kullanıcı için doğru sıralamayı korur.
✔️ Offset ve Consumer Grupları: Dayanıklı Tüketim Mantığı
📌 Offset Nedir? (Basit anlatım)
Offset aslında Kafka’nın tuttuğu “Ben en son hangi mesajı işledim?” notudur.
Bir nevi okuma kitabındaki kaldığın sayfayı işaretlemek gibi düşün.
Kafka bunu belirli aralıklarla kaydeder (commit eder).
Bu sayede:
✔️ Consumer çökse bile kaldığı yerden devam eder
Yani sistem çöktü → yeniden açtın → Kafka der ki:
“En son şu mesajı işlemişti, 1 sonrasından devam ettireyim.”
⚠️ Offset erken commit edilirse (çok erken işaretlerse)
Consumer aslında mesajı işlemeden, “işledim” diye işaretler.
Bu durumda veri kaybı olabilir çünkü mesaj hiç işlenmemiş olur.
⚠️ Offset geç commit edilirse (gecikirse)
Mesaj işlenir ama Kafka’ya “işledim” bilgisi geç gider.
Consumer yeniden başlarsa aynı mesajı tekrar işleyebilir.
Yani:
- Erken commit → veri kaybı riski
- Geç commit → duplicate işleme riski
Offset doğru yönetilmezse sistemde garip bug’lar görünür.
✔️ Consumer Group: Paralel Tüketimin Temeli
Consumer group’u şöyle düşün:
Bir topic’i tüketmek istiyorsun ama çok fazla mesaj var.
Tek consumer yavaş kalır.
Bu yüzden aynı grup içinde birden fazla consumer çalıştırırsın.
Kafka’nın sağladığı güzellik şu:
✔️ Aynı consumer group içindeki her mesaj, sadece bir consumer’a gider
Yani tüketiciler birbirinin aynısı gibi çalışır ama Kafka mesajları aralarında bölüştürür.
- Consumer A → Partition 1
- Consumer B → Partition 2
- Consumer C → Partition 3
Gibi.
✔️ Bir consumer düşerse Kafka otomatik olarak yeniden dağıtır
Mesela Consumer B çöktü:
Kafka der ki:
“Tamam, B’nin baktığı partition’ı şimdi A veya C alsın.”
Böylece sistem durmadan çalışmaya devam eder.
Bu da yüksek availability sağlar.
✔️ Mesaj Teslimat Garantileri
Kafka üç farklı garanti modeli sunar:
| Garanti | Açıklama | Dezavantaj |
|---|---|---|
| At most once | Çok hızlıdır | Mesaj kaybı olabilir |
| At least once | Mesaj kaybı olmaz | Duplikasyon riski |
| Exactly once | Kritik finansal sistemler için ideal | Kurulumu karmaşık ve daha yavaş |
✔️ Replication: Veri Kaybını Önlemek İçin Güvence
Kafka’da her partition sadece tek bir yerde tutulmaz.
Aynı partition’ın birden fazla kopyası (replica) bulunur.
Bu yapı şöyle işler:
📌 Her partition için:
- 1 tane lider (leader)
- N tane follower (genelde 2 tane)
Follower’lar leader’ın birebir aynısını tutar.
✔️ Lider Ne İş Yapar?
- Tüm okuma ve yazma işlemlerini leader yönetir.
- Follower’lar da leader’ın yazdığı mesajları sırayla kendilerine çeker.
Yani leader = aktif çalışan kopya
Follower = yedekler (backup)
✔️ Lider Çökerse Ne Olur?
Kafka burada akıllı davranır:
- Leader çökerse → follower’lardan biri otomatik olarak yeni leader olur.
- Bu işlem kullanıcıya hissettirilmez.
Sistem durmaz, veri kaybolmaz.
Bu yüzden replication Kafka’nın dayanıklılık (durability) özelliğinin temelidir.
✔️ 3 Replika Kullanılan Sistemlerde Ne Sağlanır?
Tipik yapı şudur:
1 leader + 2 follower = 3 replika
Bunun sağladığı fayda:
🎉 Bir broker çökse bile veri kaybı olmaz
Çünkü aynı partition’ın başka brokerlarda da kopyası vardır.
✔️ Daha Yüksek Güvenlik: acks=all
Mesaj producer tarafından gönderildiğinde Kafka’ya “mesajı aldın mı?” diye sorulur.
- acks=1 → Leader “aldım” der, follower’ları beklemez
- acks=all → Lider, tüm follower’ların mesajı aldığını onaylamadan “mesaj başarılı” demez
Yani:
- acks=1 → daha hızlı ama riskli
- acks=all → daha güvenli ama biraz daha yavaş
Kritik finansal sistemlerde genelde acks=all kullanılır.
✔️ Kafka’nın Güçlü Üretim Kullanım Senaryoları
Kafka sadece mesaj kuyruğu gibi çalışmaz — gerçekten dev ölçekli sistemlerin kalbidir.
Aşağıdaki iki örnek, “Kafka neden bu kadar popüler?” sorusunun pratik karşılığıdır.
1. Uber — Gerçek Zamanlı Sürücü Konumları
Uber gibi bir uygulamada, dünyadaki milyonlarca sürücü anlık olarak konum gönderiyor:
- “Sürücü X şu an burada”
- “Hareket etti”
- “Müşteriye yaklaştı”
- “Alımı yaptı”
- “Yolculuğa başladı”
Bu olaylar sürekli akar.
Saniyede milyonlarca konum mesajı demek.
Uber’de tüm bu mesaj trafiği Kafka üzerinden akar.
📌 Peki Uber nasıl ölçekliyor?
Uber, Kafka’da coğrafi partitioning kullanıyor.
Yani:
- Avrupa’nın mesajları ayrı partition’larda
- ABD’nin mesajları ayrı
- APAC bölgesi ayrı
Her bölge kendi içinde ölçekleniyor →
Bu da sistemi devasa trafiğe rağmen stabil tutuyor.
Özet:
Kafka olmasa Uber’in gerçek zamanlı harita sistemi çöker.
2. Event Sourcing — “Sistem Kayıt Defteri” Olarak Kafka
Bazı şirketler Kafka’yı sadece bir mesaj sistemi değil, adeta bir kayıt defteri (ledger) gibi kullanıyor.
Bu yaklaşımın adı: Event Sourcing
📌 Mantık çok basit:
- Sistemde bir durum değişikliği olursa → Kafka’ya event olarak yazılır.
Örneğin: “Sipariş oluşturuldu”, “Ödeme onaylandı”, “Ürün kargoya verildi”. - Güncel sistemi elde etmek için, bu event’ler sırayla tekrar oynatılır (replay).
🎯 Bu ne sağlar?
✔️ %100 audit trail
Her olay kaydedildiği için “Bu nasıl oldu?” sorusuna her zaman cevap vardır.
✔️ Mikroservis mimarisini güçlendirir
Her servis, olayları Kafka’dan okuyarak kendi state’ini çıkarır.
Servisler birbirine bağlı kalmaz → bağımsızca ölçeklenir.
Özet:
Kafka burada sadece bir mesajlaşma aracı değil, sistemin gerçeği (truth) haline gelir.
✔️ Kafka Her Durum İçin Uygun Mu? Dezavantajları Neler?
Kısa cevap: Hayır.
Kafka her sorunu çözen bir araç değildir.
Çok güçlü yanları var ama bazı senaryolarda doğru tercih olmaz.
📌 Kafka’nın güçlü olduğu alan:
Yüksek throughput → yani saniyede çok fazla mesaj işlemek.
Ama Kafka’nın zayıf olduğu alan:
Düşük latency → yani milisaniye altı tepki süreleri.
❌ Kafka’nın Uygun Olmadığı Durumlar
1️⃣ Milisaniye altı gecikme isteyen request–response sistemleri
Örneğin:
- Bir kullanıcı butona bastığında anında cevap isteyen bir sistem
- Yüksek frekanslı trading (HFT)
- Gerçek zamanlı oyun sunucuları
Bu tür yerlerde Kafka fazla ağır kalır.
Kafka daha çok “boru hattı” gibidir, “instant cevap” değil.
2️⃣ Tek bir global sıralama (strict total order) gereken senaryolar
Eğer tüm mesajların tek bir sırada olmasını istiyorsan (herkes için aynı sıra), Kafka burada zorlanır.
Bunu yalnızca şöyle yapabilirsin:
👉 Tüm mesajları tek partition’a yazmak.
Bu da neye yol açar?
- Paralellik ölür
- Hız düşer
- Kafka’nın güçlü yönü kaybolur
Yani Kafka global sıra isteyen sistemler için ideal değil.
3️⃣ Basit uygulamalar
Eğer:
- Az trafik var
- Saniyede birkaç yüz mesaj yeterli
- Küçük bir ekipsin
- Operasyonel yük istemiyorsun
Kafka gereksiz yere karmaşık olur.
Zookeeper/Yeni Raft sistemi, disk yönetimi, replication, partitioning, monitoring…
Hepsi ekstra operasyon maliyeti.
Basit bir kuyruk sistemi (RabbitMQ, SQS vs.) çok daha uygun olur.
📌 Sonuç: Kafka Neden Bu Kadar Popüler?
Kafka özellikle dev ölçekli sistemlerde parlıyor. Çünkü:
✔️ 1. Üreticiler ve tüketiciler bağımsız çalışır (decoupling)
Servisler birbirine bağlı değildir → sistem daha dayanıklı ve geliştirilebilir olur.
✔️ 2. Trafik patlamaları sisteminizi çökertmez
Kafka bir buffer gibi davranır.
Ani yük artışları Kafka tarafından emilir.
✔️ 3. Event replay ile hata ayıklamak çok kolay
Geçmişte olan her şeyi tekrar oynatabilirsin →
Bu, debugging için inanılmaz bir avantaj.
✔️ 4. Partition + replication → yüksek ölçeklenebilirlik + dayanıklılık
- Partition → paralellik
- Replication → veri kaybına karşı koruma
Bu ikisi birlikte Kafka’yı dev şirketlerin vazgeçilmezi yapıyor.
⚠️ Ama unutmamak lazım:
Kafka çok güçlü bir araç ama…
👉 Kurulumu, yönetimi ve doğru partitioning stratejisi uzmanlık ister.
Yanlış kurulan Kafka → yavaş, dengesiz ve sorunlu bir sisteme dönüşebilir.
Kaynakça:
- https://medium.com/better-programming/thorough-introduction-to-apache-kafka-6fbf2989bbc1
