1. GİRİŞ

Apache Kafka, modern veri mühendisliği ve gerçek zamanlı uygulama ihtiyaçları için en yaygın kullanılan dağıtık streaming platformlarından biridir. Yüksek throughput, düşük gecikme ve dayanıklı log yaklaşımı sayesinde telemetri, event‑sourcing, messaging ve stream processing senaryolarında tercih edilir. Bu makale, Kafka'nın mimari yapı taşlarını, çalışma mantığını, operasyonel nüanslarını ve gerçek dünya kullanım örneklerini mühendis bakış açısıyla ayrıntılı biçimde ele alır.

Bu konu neden konuşuluyor?

• Gerçek zamanlı veri işleme ve streaming uygulamalarının yaygınlaşması.
• Event‑driven ve microservice mimarilerinde durable, ölçeklenebilir iletişim hattı ihtiyacı.
• Veri ekiplerinin real‑time analytics, backfill ve audit gereksinimlerini karşılayabilen altyapıya duyduğu talep.

Kimler için önemli?

• Platform mühendisleri ve veri mühendisleri
• Backend geliştiriciler ve mimarlar
• SRE ve operasyon ekipleri

Hangi problemleri çözüyor?

• Yüksek hacimli veriyi düşük gecikmeyle taşıma ve işleme
• Event replay ve backfill yetenekleri ile veri kurtarma ve yeniden hesaplama
• Dağıtık sistemler için fault tolerance ve ölçeklenebilirlik

2. KAVRAMSAL TEMELLER

2.1 Kafka'nın temel kavramları

Topic

Event'lerin kategorize edildiği logical kanal. Üreticiler topic'e publish eder, tüketiciler topic'ten okur.

Partition

Topic'in paralel işlenebilir parçası. Her partition immutable append‑only log olarak tutulur ve ordered processing sağlar.

Offset

Partition içindeki her event'in sırası; tüketicilerin konumunu belirler.

Producer

Event üreten client uygulama.

Consumer

Event'leri okuyan ve işleyen client uygulama. Consumer group ile paralel işleme sağlanır.

Broker (Kafka broker)

Partition veri parçalarını saklayan ve client'lara hizmet eden sunucu süreçleri.

Replica

Partition verisinin bir kopyası; replication replication factor ile sağlanır.

Leader / Follower

Her partition için bir leader belirlenir; followers leader'dan replikasyonla veri alır. Tüm yazma/okuma istekleri leader üzerinden yönetilir (konfigürasyona bağlı olarak okunabilir followers'tan da yapılabilir).

ISR (In‑Sync Replicas)

Leader ile güncel durumda olan replica set'i; write durability ve ack politikaları için önemlidir.

2.2 Kafka ekosisteminden diğer bileşenler

• ZooKeeper / KRaft: Kafka'nın metadata, cluster yönetimi ve leader election için kullandığı koordinasyon mekanizması. (Yeni Kafka sürümleri KRaft modu ile ZooKeeper olmadan çalışabiliyor.)
• Schema Registry: Event formatlarının versiyonlanması ve uyumluluk politikalarının yönetimi için kullanılır (Confluent Schema Registry veya alternatif çözümler).
• Kafka Connect: Veri entegrasyonları için connector'lar; veriyi sistemler arası taşımayı kolaylaştırır.
• Kafka Streams, ksqlDB, Flink: Stream processing ve stateful transformasyon araçları.

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ VE AKIŞ

3.1 Partitioning ve ordered processing

Partition'lar Kafka'nın paralelleşme ve ölçeklenebilirlik modelinin çekirdeğidir. Bir topic N partition'a bölünürse, aynı anda en fazla N paralel tüketici (aynı consumer group içinde) o topic'i tüketebilir. Partition key (ör. userId, orderId) kullanılarak aynı anahtara sahip event'lerin aynı partition'a yönlendirilmesi sağlanır ve bu sayede o anahtar için ordering garantisi korunur.

3.2 Replication, durability ve ISR

Replication factor, partition verisinin kaç kopyada saklanacağını belirler. Her partition için bir leader ve bir veya daha fazla follower bulunur. Followers leader'ı takip ederek veriyi replik eder. ISR, leader ile senkron durumda kalan replica'ların listesidir. Yazma işlemleri için ACK politikaları (acks=0, acks=1, acks=all) ve ISR ilişkili olarak veri güvenliğini ve performansı dengeler. "acks=all" ve yeterli ISR ile veri kaybı riskini minimize edebilirsiniz, ancak yazma gecikmesi artar.

3.3 Offset yönetimi ve tüketici grupları

Consumer group konsepti, paralel tüketimi ve load balancing'i sağlar. Her consumer group içindeki tüketiciler topic partition'larını paylaşır; bir partition aynı anda bir group içindeki tek consumer tarafından işlenir. Offset'ler Zookeeper veya Kafka içindeki __consumer_offsets topic'inde saklanır; offset commit stratejileri (auto commit veya manual commit) tüketim güvenliğini etkiler.

3.4 Log yapısı, retention ve compaction

Kafka'da veriler append‑only log şeklinde saklanır. Retention policy ile event'lerin ne kadar süre veya ne kadar disk alanı için saklanacağı belirlenir. Log compaction seçeneği, topic içindeki en son key bazlı durumun saklanmasını sağlar — state change log'ları için idealdir. Retention ve compaction'ın kombinasyonu, depolama maliyeti ve veri geri yükleme yetenekleri arasında trade‑off sunar.

3.5 Delivery semantics ve idempotency

Kafka varsayılan olarak at‑least‑once teslim sağlar. Yani tüketicilerin duplicate event'leri işleyebileceği kabul edilmelidir; bu nedenle tüketiciler idempotent iş mantığına sahip olmalıdır. Exactly‑once semantics (EOS) Kafka'nın transactional API'leri ve stream processing framework'leri ile kısmi olarak desteklenir; dikkatli tasarım ve koordinasyon gerektirir.

3.6 Rebalancing ve partition leadership

Consumer group üyelerinde değişiklik (consumer ekleme/çıkarma, partition değişimi) olduğunda rebalancing gerçekleşir; bu süreç partition'ların yeniden atanmasına ve kısa bir tüketim durmasına (pause) neden olabilir. Rebalance listener'ları ve incremental cooperative rebalancing gibi modern yaklaşımlar bu süreyi minimize etmeye çalışır. Ayrıca broker tarafında partition leadership değişimleri network partition veya broker failover durumlarında meydana gelir; bunların hızlı ve güvenilir yönetimi operasyon açısından kritiktir.

4. GERÇEK DÜNYA KULLANIMLARI

Netflix / Telemetry ve personalization

Netflix, kullanıcılardan gelen telemetri, oynatma olayları ve hizmet metriklerini yüksek hacimle Kafka'ya yazıp downstream stream processing ile anlık kişiselleştirme ve kalite temelli kararlar alır. Kafka aynı zamanda backfill ve replay için altyapı sağlar.

Uber / Real‑time dispatch

Uber, düşük gecikmeli event stream'ler ile konum, talep ve sürücü durumunu işleyerek dispatch kararları verir. Kafka benzeri sistemler, yüksek throughput ve dayanıklılık sağlamak için kullanılmıştır.

Fintech — Ödeme iş akışları ve reconciliations

Finansal uygulamalarda Kafka, ödeme event'lerini, reconciliations ve audit pipeline'larını destekler. Exactly‑once veya deterministik compensating logic gerektiren senaryolarda Kafka transactional özellikleri ve dikkatli tasarım kritik olur.

Data platformları ve ETL

Kafka Connect ile veriyi veri tabanlarından, object storage'den ve üçüncü parti servislerden çekip stream'leyerek merkezi data lake veya data warehouse'a taşıma yaygındır. Connect'in connector ekosistemi entegrasyon maliyetini düşürür.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Yüksek throughput ve düşük gecikme: Disk tabanlı append log ve batching mekanizmaları sayesinde verimli veri iletimi sağlar.
• Durability ve replay: Event log'ları sayesinde geçmiş veriyi yeniden oynatma (replay) mümkündür.
• Ekosistem: Kafka Streams, Kafka Connect ve üçüncü parti araçlar geniş bir ekosistem sunar.

Sınırlamalar

• Operasyonel maliyet: Broker cluster yönetimi, maintenance, disk/IO yönetimi ve rebalancing gibi operasyonel sorumluluklar vardır.
• Kompleks konfigürasyon: Partitioning, replication, acknowledgment behavior ve retention ayarları uygulamaya bağlı ince ayar gerektirir.
• Exactly‑once zorluğu: EOS bazı senaryolarda karmaşık ve kaynak gerektiren bir çözümdür; her zaman gerekmeyebilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Topic ve partition tasarımını iş yüküne göre planlayın; hot key testleri yapın.
• Replication factor ve ISR hedeflerini SLA gereksinimlerine göre belirleyin; ACK politikasını doğru seçin.
• Schema registry kullanarak schema evolution ve uyumluluğu yönetin.

Performans optimizasyonu

• Producer tarafında batching, linger.ms ve compression (snappy, lz4) kullanın.
• Consumer paralelleştirmesini partition sayısı ile dengeleyin; thread pool yönetimini iyileştirin.
• Disk I/O ve JVM GC optimizasyonlarına dikkat edin; broker node'larında yeterli kaynak planlayın.

Güvenlik

• Broker ve client iletişimini TLS ile şifreleyin; authentication (SASL/OAUTH) ve ACL ile yetkilendirme uygulayın.
• Hassas veriyi event içinde taşımamaya çalışın; referans veya token kullanın ve encryption at‑rest uygulayın.

Ölçeklenebilirlik ve operasyon

• Monitoring: broker metrics, partition lag, under‑replicated partitions, disk usage ve GC metriklerini izleyin.
• Capacity planning: retention ve expected throughput'a göre disk, ağ ve CPU kaynaklarını planlayın.
• DR: cross‑region replication ve disaster recovery playbook'ları oluşturun; test edilmiş failover senaryolarınız olsun.

8. SIK YAPILAN HATALAR

• Partition count'ı yetersiz belirlemek — sonradan paralelleme maliyetlidir.
• Retention ve disk planlamasını ihmal etmek — broker disk dolması cluster stabilitesini bozar.
• Idempotency tasarımını göz ardı etmek — duplicate processing veri tutarsızlığına yol açar.
• Monitoring ve alert konfigürasyonunu eksik kurmak — under‑replicated veya offline partition'lar geç fark edilir.

9. GELECEK TRENDLER

1. KRaft ve ZooKeeper'siz Kafka: Kafka'nın kendi metadata yönetimini entegre etmesi operasyonel basitleştirme sağlayacak.
2. Transactional stream processing: Exactly‑once ve transactional processing yetenekleri daha olgun hale gelecek.
3. Hybrid ve multi‑cloud replication: Geo‑replication ve event mesh konseptleri yaygınlaşacak.
4. AI destekli ops: Otomatik partition rebalancing önerileri, anomaly detection ve kapasite planlama çözümleri gelişecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Kafka mı yoksa Pulsar mı seçmeliyim?

   İhtiyacınıza göre. Kafka geniş ekosistem ve topluluk desteği sunar; Pulsar multi‑tenant, yerleşik geo‑replication ve tiered storage avantajlarıyla öne çıkar. Operasyon, özellik seti ve uzun vadeli roadmap'e göre değerlendirme yapın.

2. 2. Partition sayısını nasıl belirlemeliyim?

   Beklenen maksimum throughput ve paralel tüketici sayısı, consumer group büyüklüğü ve hot key davranışı göz önünde bulundurularak belirlenir. Test yükleriyle doğrulama şarttır.

3. 3. Exactly‑once mümkün mü?

   Kısıtlı senaryolarda Kafka transactions ve idempotent producers ile sağlanabilir. Stream processing framework'lerin (Flink, Kafka Streams) transactional özellikleri kullanılarak EOS benzeri çözümler elde edilebilir fakat tasarım karmaşıktır.

4. 4. Schema evolution nasıl yönetilir?

   Schema Registry kullanın, semantic versioning ve compatibility policy (backward/forward) ile tüketicilerin kırılmasını önleyin. Yeni alanlar optional eklenmeli, zorunlu alan değişiklikleri dikkatle planlanmalıdır.

5. 5. Broker için hangi donanımı planlamalıyım?

   Disk IO (throughput ve IOPS), ağ bant genişliği ve bellek öncelikli gereksinimlerdir. NVMe veya hızlı SSD'ler, yüksek retention senaryolarında ölçeklenebilirlik için kritik olabilir.

6. 6. Rebalancing sırasında nasıl davranmalıyım?

   Incremental cooperative rebalancing ve consumer uygulamalarında state checkpoint'lerini tutma stratejileri kullanın. Rebalance sürelerini azaltmak için consumer group yapılandırmalarını optimize edin.

7. 7. Log compaction ne zaman kullanılmalı?

   Change‑log ve state store senaryolarında, sadece son state'in saklanması istendiğinde compaction uygundur. Tarihsel tüm event'lerin tutulması gerekiyorsa retention tercih edilir.

8. 8. Kafka cluster'ı nasıl izlemeliyim?

   Broker metrics (leader/follower status, under‑replicated partitions), partition lag, consumer throughput, disk usage ve JVM GC metriklerini izleyin. Alert'leri SLA hedeflerine göre tanımlayın.

Anahtar Kavramlar

Partition

Topic'in paralel işlenebilir parçası; ordered processing sağlar.

ISR

Leader ile senkron durumda olan replica'ların set'i; veri dayanıklılığı için önemlidir.

Offset

Tüketicinin partition içerisindeki pozisyonunu gösterir.

Log Compaction

Key bazlı en son değerin saklanmasını sağlayan optimizasyon.

Exactly‑once (EOS)

Duplicate olmadan tek seferlik işleme garantisi; Kafka transactional API'leri ile kısmi destek vardır.

Öğrenme Yol Haritası

1. 0–1 ay: Kafka temel kavramları (topic, partition, offset, producer, consumer) ve basit producer/consumer uygulamaları ile başlayın.
2. 1–3 ay: Partitioning, replication, ISR ve offset commit stratejilerini test edin; mini cluster ile temel operasyonları deneyin.
3. 3–6 ay: Kafka Connect, Schema Registry ve Kafka Streams veya Flink ile stream processing uygulamaları geliştirin; retention, compaction ve rebalancing senaryolarını uygulayın.
4. 6–12 ay: Production ops: cluster capacity planning, cross‑region replication, DR prova fikirleri ve exactly‑once senaryolarında pratik yapın.