Kafka Bir Kuyruk Değildir: Sisteminizi Mahvetmekten Nasıl Kaçınırsınız?

Kafka Bir Kuyruk Değildir: Sisteminizi Mahvetmekten Nasıl Kaçınırsınız?

Kafka’nın bir mesaj kuyruğu olmadığını anlamak, dağıtık sistemlerinizin performansını ve ölçeklenebilirliğini kritik ölçüde etkiler. Yanlış kullanım senaryolarından kaçınarak veri akışlarınızı optimize edin ve mimarinizi güçlendirin. Bu makale, Kafka’nın gerçek potansiyelini keşfetmenize yardımcı olacak.

Giriş: Kafka Yanlış Anlaşıldığında Neler Olur?

Günümüzün hızla değişen dijital dünyasında, işletmeler ve yazılım geliştiriciler, veri akışlarını yönetmek, işlemek ve depolamak için güçlü araçlara ihtiyaç duyar. Bu araçlar arasında Apache Kafka, dağıtık sistemler için vazgeçilmez bir platform olarak öne çıkar. Ancak ne yazık ki, Kafka’nın temel mimarisi ve kullanım amacı sıklıkla yanlış anlaşılır. Pek çok geliştirici, Kafka’yı geleneksel bir mesaj kuyruğu (message queue) gibi ele alır ve bu yanlış algı, sistemlerinin performansını, güvenilirliğini ve ölçeklenebilirliğini ciddi şekilde olumsuz etkileyebilir. Peki, bu yanlış anlama neden bu kadar yaygın ve sistemlerimizi nasıl felakete sürükleyebilir?

Geleneksel mesaj kuyrukları, genellikle mesajların bir kez tüketilmesi ve ardından kuyruktan silinmesi prensibiyle çalışır. Bu yapı, birçok senaryo için uygun olsa da, Kafka’nın sunduğu yeteneklerin çok gerisinde kalır ve onun temel tasarım felsefesine aykırıdır. Kafka, basit bir kuyruk olmaktan öte, yüksek performanslı, dağıtık bir akış platformudur. Bu platform, olay akışlarını kalıcı olarak depolayabilir, birden fazla tüketici grubunun aynı veriyi farklı hızlarda ve amaçlarla işlemesine olanak tanır ve gerçek zamanlı veri entegrasyonu ile analiz için güçlü bir temel sunar. Eğer Kafka’yı sadece “mesajları bir yerden alıp başka bir yere ileten bir boru” olarak görürseniz, onun sunduğu veri kalıcılığı, yeniden oynatma (replay) yeteneği ve eş zamanlı tüketim gibi kritik avantajları göz ardı etmiş olursunuz.

Bu yanlış kullanım, kaçınılmaz olarak sistemlerde darboğazlara, veri kaybı riskine, gereksiz karmaşıklığa ve operasyonel yükün artmasına yol açar. Örneğin, bir e-ticaret uygulamasında, sipariş verilerini Kafka’ya gönderip, bu veriyi sadece bir kez işleyecek tek bir tüketici grubuyla çalışmak, Kafka’nın gerçek gücünü kullanmamaktır. Oysa aynı sipariş verisi, stok güncellemeleri, kargo takibi, kişiselleştirilmiş öneriler ve finansal raporlama gibi farklı departmanlar tarafından eş zamanlı olarak ve bağımsız bir şekilde işlenebilir. Kafka’nın bu çoklu tüketici yeteneği, geleneksel bir kuyruk sistemiyle elde edilemez.

Bu makalede, Kafka’nın neden bir kuyruk olmadığını ayrıntılı bir şekilde inceleyeceğiz. Temel kavramlarını açıklayacak, onu bir kuyruk gibi kullanmanın getirdiği tehlikeleri vurgulayacak ve gerçek bir olay akışı platformu olarak nasıl kullanılması gerektiğini örneklerle göstereceğiz. Amacımız, Kafka’yı doğru bir şekilde anlayarak, sistemlerinizin performansını ve güvenilirliğini en üst düzeye çıkarmanıza yardımcı olmaktır. Böylece, hem mevcut sorunları çözebilir hem de gelecekteki büyüme ve gelişme için sağlam bir temel oluşturabilirsiniz.

Kafka Nedir ve Geleneksel Kuyruklardan Neden Farklıdır?

Apache Kafka, LinkedIn tarafından geliştirilen ve daha sonra açık kaynak olarak sunulan, dağıtık bir akış platformudur (distributed streaming platform). Temel amacı, yüksek hacimli olay akışlarını (event streams) güvenilir bir şekilde yönetmek, depolamak ve işlemek için bir omurga sağlamaktır. Kafka, bir mesaj kuyruğu olmaktan ziyade, dağıtık bir commit log (taahhüt günlüğü) veya olay günlüğü olarak düşünülebilir. Bu temel farklılık, Kafka’yı geleneksel mesaj kuyruklarından ayıran en önemli özelliktir.

Kafka’nın Temel Bileşenleri Nelerdir?

Kafka’nın mimarisi, birkaç ana bileşenden oluşur ve her biri platformun genel işleyişinde kritik bir rol oynar:

• Producers (Üreticiler): Uygulamalar veya servisler tarafından üretilen olayları (mesajları) Kafka’ya gönderen istemcilerdir. Üreticiler, mesajları belirli bir konuya (topic) yazarlar.
• Consumers (Tüketiciler): Kafka’daki konulardan olayları okuyan istemcilerdir. Tüketiciler, bir veya daha fazla tüketici grubuna (consumer group) ait olabilir ve her grup, aynı konudaki mesajları bağımsız olarak işleyebilir.
• Brokers (Aracılar): Kafka kümesini oluşturan sunuculardır. Her broker, birden fazla konunun (topic) belirli bölümlerini (partitions) barındırır ve gelen olayları depolar. Brokerlar arasında veri çoğaltma (replication) yapılarak yüksek erişilebilirlik ve hata toleransı sağlanır.
• Topics (Konular): Olayların kategorize edildiği mantıksal kanallardır. Üreticiler belirli bir konuya mesaj gönderirken, tüketiciler belirli bir konudan mesaj okur. Bir konu, bir veya daha fazla bölüme ayrılabilir.
• Partitions (Bölümler): Bir konunun fiziksel olarak ayrılmış, sıralı ve değişmez (immutable) bir olay kaydıdır. Her bölüm, kendi içinde sıralı bir mesaj akışına sahiptir ve mesajlar bir offset (uzaklık) değeriyle tanımlanır. Bölümler, Kafka’nın ölçeklenebilirlik mekanizmasının temelini oluşturur.
• Offsets (Uzaklıklar): Her bölümdeki her olayın benzersiz, sıralı bir kimliğidir. Tüketiciler, bir bölümdeki okuma konumlarını bu offset değerleriyle takip ederler. Bu, tüketicilerin mesajları nerede bıraktıklarını bilmelerini ve gerektiğinde kaldıkları yerden devam etmelerini sağlar.

Kuyruk Sistemlerinin Karakteristik Özellikleri Nelerdir?

Geleneksel mesaj kuyrukları (örneğin RabbitMQ, ActiveMQ), genellikle aşağıdaki özelliklere sahiptir:

• Tekil Tüketim (Single Consumption): Bir mesaj bir kez bir tüketici tarafından okunduğunda, genellikle kuyruktan silinir ve başka bir tüketici tarafından tekrar okunamaz. Bu, mesajların işlendikten sonra kaybolduğu anlamına gelir.
• Mesaj Silme ve Kalıcılık Eksikliği (Message Deletion and Lack of Persistence): Mesajlar, işlendikten sonra kuyruktan kaldırılır. Bu durum, geçmiş olaylara dönüp bakma veya sistemin durumunu yeniden oluşturma yeteneğini sınırlar.
• FIFO Sırası (First-In, First-Out Order): Çoğu geleneksel kuyruk, mesajların gönderilme sırasına göre tüketileceğini garanti eder. Ancak bu sıra genellikle küreseldir ve ölçeklenebilirlik arttığında yönetimi zorlaşabilir.
• Durum Yönetimi (State Management): Kuyruk sistemleri genellikle mesajların teslim edildiğini veya işlendiğini takip etmek için iç mekanizmalara sahiptir, ancak bu durum genellikle mesajın ömrüyle sınırlıdır.

Kafka Neden Farklıdır?

Kafka’nın geleneksel kuyruklardan temel farkları şunlardır:

• Değişmez ve Kalıcı Olay Günlüğü (Immutable and Persistent Event Log): Kafka’daki mesajlar (olaylar), bir kez yazıldıktan sonra değiştirilemez veya silinemez. Bunun yerine, belirlenen bir saklama süresi (retention period) boyunca diskte kalıcı olarak depolanır. Bu süre dolduğunda, eski mesajlar otomatik olarak silinir. Bu özellik, olaylara tekrar erişme ve onları yeniden işleme (replay) yeteneği sağlar.
• Çoklu Tüketici Grupları (Multiple Consumer Groups): Kafka’daki aynı olay akışı, birden fazla bağımsız tüketici grubu tarafından eş zamanlı olarak ve farklı hızlarda işlenebilir. Her tüketici grubu, kendi offset’ini (okuma konumunu) tutar ve bu, aynı verinin farklı iş akışları için kullanılmasına olanak tanır. Örneğin, bir sipariş olayı, hem stok yönetimi hem de müşteri bilgilendirme sistemi tarafından aynı anda tüketilebilir.
• Bölüm Tabanlı Sıra Garantisi (Partition-Based Order Guarantee): Kafka, bir bölüm içindeki mesajların sırasını garanti eder. Yani, bir üretici belirli bir bölüme mesajları hangi sırayla gönderdiyse, tüketiciler de o bölümden mesajları aynı sırayla okuyacaktır. Ancak farklı bölümler arasındaki mesajların genel bir sırası garanti edilmez. Bu, Kafka’nın yatay ölçeklenebilirliğini mümkün kılar.
• Yüksek Ölçeklenebilirlik ve Hata Toleransı (High Scalability and Fault Tolerance): Kafka, dağıtık bir sistem olarak tasarlandığı için yatay olarak kolayca ölçeklenebilir. Bölümler ve çoğaltma (replication) mekanizmaları sayesinde, broker arızalarına karşı dayanıklıdır ve veri kaybını minimize eder.
• Akış İşleme Yetenekleri (Stream Processing Capabilities): Kafka, sadece veri taşıma aracı değil, aynı zamanda Kafka Streams API veya ksqlDB gibi araçlarla gerçek zamanlı akış işleme yetenekleri de sunar. Bu, olay akışları üzerinde dönüşümler, birleştirmeler ve analizler yapılmasına olanak tanır.

Özetle, Kafka bir “olay akışı platformu” olup, veriyi kalıcı, sıralı ve çoklu tüketici senaryolarına uygun bir şekilde yönetir. Geleneksel kuyruklar ise genellikle geçici, tekil tüketimli ve sınırlı kalıcılığa sahip mesaj dağıtım sistemleridir. Bu fundamental farkı anlamak, Kafka’yı doğru ve verimli bir şekilde kullanmanın anahtarıdır.

Kafka’yı Kuyruk Gibi Kullanmanın Tehlikeleri Nelerdir?

Kafka’nın bir mesaj kuyruğu olmadığını kabul etmek, sistem mimarinizi doğru bir şekilde tasarlamanız için kritik bir adımdır. Ancak bu ayrımı göz ardı edip Kafka’yı geleneksel bir kuyruk gibi kullanmaya çalışmak, çeşitli teknik ve operasyonel sorunlara yol açabilir. Bu sorunlar, performans düşüşlerinden veri tutarsızlıklarına, hatta sistem çöküşlerine kadar uzanabilir. İşte Kafka’yı bir kuyruk gibi kullanmanın getirdiği başlıca tehlikeler:

Mesaj Kaybı ve Veri Tutarsızlığı Riskleri Nasıl Ortaya Çıkar?

Geleneksel kuyruk sistemlerinde, bir mesaj tüketildiğinde kuyruktan silinir. Bu, mesajın bir kez ve bir tüketici tarafından işlendiği garantisini verir. Ancak Kafka’da durum farklıdır; mesajlar belirli bir süre boyunca (retention period) kalıcı olarak diskte tutulur ve tüketiciler sadece okuma konumlarını (offset) ilerletir. Kafka’yı bir kuyruk gibi kullanmaya çalışanlar, bu temel mekanizmayı yanlış anlayarak veya yanlış yapılandırarak veri kaybı riskini artırabilirler.

• Yanlış Offset Yönetimi: Tüketicilerin offset’lerini manuel olarak veya yanlış zamanda kaydetmesi, mesajların yeniden işlenmesine (duplicate processing) veya hiç işlenmemesine (data loss) neden olabilir. Örneğin, bir tüketici mesajları işledikten sonra offset’i kaydetmeden önce çökerse, yeniden başladığında aynı mesajları tekrar işleyebilir veya daha da kötüsü, offset’i yanlış bir konuma kaydedip bazı mesajları atlayabilir.
• Mesajların Yanlışlıkla Atlanması: Eğer bir konunun (topic) sadece bir bölümü (partition) varsa ve birden fazla tüketici, aynı tüketici grubunda değil de bağımsız olarak o bölümden okumaya çalışırsa, Kafka’nın varsayılan davranışı nedeniyle bu tüketicilerden sadece biri mesajları alacaktır. Diğerleri mesajları kaçırabilir. Bu durum, özellikle “tekil tüketim” beklenen senaryolarda büyük bir veri tutarsızlığına yol açar.
• Kalıcılık Süresinin Yanlış Anlaşılması: Kafka, mesajları belirli bir süre veya boyut limitine kadar saklar. Eğer bir tüketici, belirlenen kalıcılık süresi içinde mesajları işleyemezse, bu mesajlar diskten silinir ve tüketici onları bir daha okuyamaz. Geleneksel kuyruklarda mesajlar işlenene kadar kuyrukta beklerken, Kafka’da bu durum mesaj kaybına neden olabilir.

Performans Düşüşleri ve Ölçeklenebilirlik Sorunları Neden Yaşanır?

Kafka, yatay ölçeklenebilirlik için tasarlanmıştır. Bu, mesajların birden fazla bölüme dağıtılması ve bu bölümlerin birden fazla broker üzerinde barındırılmasıyla sağlanır. Ancak Kafka’yı bir kuyruk gibi kullanma eğilimi, bu ölçeklenebilirlik avantajlarını ortadan kaldırabilir.

• Tek Bölüme Yığılma (Single Partition Bottleneck): Eğer bir konu (topic) sadece tek bir bölüme sahipse veya tüm mesajlar belirli bir anahtar (key) kullanılarak aynı bölüme yönlendiriliyorsa, tüm iş yükü o tek bölüme ve onu işleyen tüketiciye düşer. Bu, sistemde ciddi bir darboğaz oluşturur ve Kafka’nın dağıtık yapısının sunduğu paralel işleme yeteneklerini kullanamaz hale gelirsiniz. Örneğin, bir e-ticaret sitesinde tüm siparişleri tek bir bölüme göndermek, sipariş hacmi arttıkça sistemin yavaşlamasına neden olacaktır.
• Yanlış Anahtar Seçimi (Suboptimal Keying): Kafka’da mesajlar genellikle bir anahtar (key) kullanılarak belirli bir bölüme atanır. Eğer anahtar seçimi dengesizse (örneğin, tüm mesajlar null key ile gönderilirse veya sadece birkaç anahtar sürekli kullanılırsa), mesajlar bölümler arasında eşit dağılmaz. Bu da bazı bölümlerin aşırı yüklenmesine, diğerlerinin ise boş kalmasına yol açar, dolayısıyla performans düşüşleri yaşanır.
• Gereksiz Senkronizasyon ve Kilitlenmeler: Geleneksel kuyrukların tekil tüketim modelini Kafka’da taklit etmeye çalışmak, tüketiciler arasında gereksiz senkronizasyon mekanizmaları veya harici kilitler kullanmaya itebilir. Bu tür ek katmanlar, performansı olumsuz etkiler ve dağıtık sistemlerin karmaşıklığını artırır.

Operasyonel Karmaşıklık ve Bakım Yükü Nasıl Artar?

Kafka’nın doğasına aykırı bir şekilde kullanılması, operasyonel olarak da baş ağrılarına neden olabilir.

• Yanlış İzleme ve Uyarılar (Incorrect Monitoring and Alerting): Kafka’nın metrikleri, onun bir akış platformu olduğu varsayımıyla tasarlanmıştır. Eğer siz onu bir kuyruk gibi izlemeye çalışırsanız, doğru uyarıları kurmakta zorlanabilir veya yanlış pozitif/negatif alarmlarla karşılaşabilirsiniz. Örneğin, kuyruk derinliği gibi geleneksel kuyruk metrikleri Kafka için yanıltıcı olabilir.
• Gereksiz Kod ve Mantık Karmaşıklığı: Kafka’nın sunduğu doğal yetenekleri (örneğin, birden fazla tüketici grubu) kullanmak yerine, kuyruk benzeri davranışları taklit etmek için uygulama katmanında karmaşık iş mantığı yazmak zorunda kalabilirsiniz. Bu, kodun bakımını zorlaştırır, hata yapma olasılığını artırır ve geliştirme sürecini yavaşlatır.
• Kaynak İsrafı: Mesajların kalıcılığı, Kafka’nın önemli bir özelliğidir. Ancak eğer mesajları işlendikten hemen sonra silmek isteyen bir kuyruk gibi kullanmaya çalışırsanız, gereksiz yere disk alanı tüketirsiniz. Bu durum, özellikle yüksek hacimli veri akışlarında maliyetli olabilir ve operasyonel yükü artırır.

Özetle, Kafka’yı bir kuyruk gibi görmek, onun temel güçlü yönlerini (kalıcılık, çoklu tüketim, yatay ölçeklenebilirlik) görmezden gelmek ve sisteminizi zayıf, kırılgan ve yönetilmesi zor bir hale getirmektir. Doğru bir anlayış ve mimari yaklaşım, Kafka’nın gerçek potansiyelini ortaya çıkarmanın ve sistemlerinizi geleceğe hazırlamanın anahtarıdır.

Kafka’nın Gerçek Gücü: Akış Platformu Olarak Nasıl Kullanılır?

Kafka’nın bir mesaj kuyruğu olmadığını ve onunla bu şekilde etkileşim kurmanın getirdiği tehlikeleri anladığımıza göre, şimdi Kafka’nın gerçek potansiyelini nasıl ortaya çıkarabileceğimizi ve onu bir olay akışı platformu olarak nasıl kullanabileceğimizi inceleyelim. Kafka’nın gücü, sadece mesajları taşımakla kalmayıp, aynı zamanda onları kalıcı olarak depolaması, birden fazla tüketici grubuna hizmet etmesi ve gerçek zamanlı akış işleme yetenekleri sunmasıdır.

Olay Akış İşleme (Event Stream Processing) Nedir?

Olay akış işleme, sürekli akan veri akışları (olaylar) üzerinde gerçek zamanlı olarak analiz, dönüşüm ve işleme yapma yeteneğidir. Kafka, bu tür mimarilerin temelini oluşturur. Geleneksel “veri tabanına yaz, sonra oku” modelinin aksine, olay akış işleme, verinin oluştuğu anda işlenmesini sağlar.

• Gerçek Zamanlı Veri Analizi: Bir e-ticaret sitesinde, müşterilerin ürünleri görüntüleme, sepete ekleme veya satın alma eylemleri birer olaydır. Bu olayları Kafka üzerinden akış olarak işleyerek, anlık olarak kişiselleştirilmiş ürün önerileri sunabilir, sepet terk etme oranlarını izleyebilir veya dolandırıcılık girişimlerini tespit edebilirsiniz. Örneğin, bir kullanıcının son 5 dakikadaki 10 farklı ürünü 30 saniye içinde sepete eklemesi, şüpheli bir aktivite olarak algılanıp anında uyarı verebilir.
• CDC (Change Data Capture – Değişiklik Veri Yakalama): Veritabanlarındaki değişiklikleri (ekleme, güncelleme, silme) gerçek zamanlı olarak yakalayıp Kafka’ya olay olarak göndermek, farklı sistemlerin bu değişikliklere anında tepki vermesini sağlar. Bu, mikroservis mimarilerinde veritabanı senkronizasyonu veya veri ambarlarının güncel tutulması için hayati öneme sahiptir. Örneğin, bir kullanıcının adres bilgisi güncellendiğinde, bu değişiklik anında Kafka’ya bir olay olarak gönderilir ve kargo, faturalandırma veya pazarlama sistemleri bu güncellemeyi anında alıp kendi verilerini senkronize edebilir.
• Log Toplama ve Metrik İzleme: Uygulama loglarını ve performans metriklerini merkezi bir Kafka kümesine toplamak, daha sonra bu verileri Elasticsearch, Splunk veya Prometheus gibi araçlarla analiz etmek için güçlü bir temel oluşturur. Bu sayede, sisteminizdeki sorunları anında tespit edebilir ve performans darboğazlarını proaktif olarak giderebilirsiniz.

Kafka Streams API veya ksqlDB gibi araçlar, doğrudan Kafka üzerinde akış işleme uygulamaları yazmayı kolaylaştırır. Bu sayede, karmaşık ETL (Extract, Transform, Load) süreçleri yerine, hafif ve gerçek zamanlı veri dönüşüm boru hatları oluşturabilirsiniz.

// Örnek Kafka Streams uygulaması: Sipariş akışından toplam sipariş değerini hesaplama
KStream<String, Order> ordersStream = builder.stream("orders-topic", Consumed.with(Serdes.String(), new OrderSerde()));

KTable<String, Double> totalRevenue = ordersStream
    .groupByKey()
    .aggregate(
        () -> 0.0, // Initializer
        (key, order, aggregate) -> aggregate + order.getAmount(), // Aggregator
        Materialized.as("total-revenue-store").with(Serdes.String(), Serdes.Double())
    );

totalRevenue.toStream().to("total-revenue-topic", Produced.with(Serdes.String(), Serdes.Double()));
    

Yukarıdaki Java kodu örneği, Kafka Streams API kullanarak nasıl bir olay akışının (orders-topic) işlenip, anahtara (örneğin müşteri ID’si) göre gruplandırılarak toplam gelir (total-revenue-topic) hesaplandığını göstermektedir. Bu, Kafka’nın sadece bir taşıma katmanı değil, aynı zamanda güçlü bir hesaplama motoru olarak da kullanılabileceğinin bir kanıtıdır.

Birden Fazla Tüketici Grubu ile Ölçeklenebilirlik Nasıl Sağlanır?

Kafka’nın geleneksel kuyruklardan en önemli farklarından biri, aynı olay akışını birden fazla, bağımsız tüketici grubunun aynı anda ve farklı amaçlar için işleyebilmesidir. Bu, sistemlerinizi inanılmaz derecede esnek ve ölçeklenebilir hale getirir.

• Paralel İş Akışları: Bir e-ticaret uygulamasında, yeni bir sipariş olayı Kafka’ya gönderildiğinde, bu olayı farklı tüketici grupları aşağıdaki gibi işleyebilir:
  • StokYonetimiGrubu: Sipariş edilen ürünlerin stoklarını günceller.
  • KargoTakipGrubu: Kargo firmasına gönderim emri oluşturur.
  • MusteriBildirimGrubu: Müşteriye sipariş onayı e-postası gönderir.
  • FinansRaporlamaGrubu: Muhasebe sistemine gelir kaydını yapar.

  Bu grupların her biri, aynı olayı kendi hızında ve kendi mantığına göre işler. Bir grubun yavaşlaması veya hata vermesi, diğer grupların işleyişini etkilemez. Bu, sistemin genel dayanıklılığını artırır ve bağımsız servislerin kendi sorumluluklarını yerine getirmesini sağlar.

• Tüketici Grubunun Mantığı: Bir tüketici grubu içindeki tüketiciler, bir konunun bölümlerini paylaşarak yük dengelemesi yapar. Örneğin, 3 bölümlü bir konuya 2 tüketici atanırsa, bir tüketici 2 bölümü, diğeri ise 1 bölümü işleyebilir. Eğer 3 tüketici atanırsa, her tüketici 1 bölümü işler. Bu model, tüketici uygulamalarınızın yatay olarak ölçeklenmesini ve iş yükünü dağıtmasını kolaylaştırır. Yeni bir tüketici eklendiğinde, Kafka otomatik olarak bölümleri yeniden atar (rebalance).

Veri Kalıcılığı ve Yeniden Oynatma Yeteneği Ne Anlama Gelir?

Kafka’nın olayları belirli bir süre boyunca kalıcı olarak depolaması, onun en güçlü özelliklerinden biridir ve geleneksel kuyruklarda bulunmayan bir avantajdır.

• Zaman Tabanlı veya Boyut Tabanlı Saklama: Kafka’da her konu (topic) için bir saklama politikası (retention policy) belirlenir. Bu politika, mesajların ne kadar süreyle (örneğin, 7 gün) veya ne kadar boyuta ulaşana kadar (örneğin, 1 TB) saklanacağını tanımlar. Bu süre veya boyut aşıldığında, en eski mesajlar otomatik olarak silinir.
• Sistem Kurtarma ve Hata Ayıklama: Eğer bir tüketici uygulamasında bir hata oluşursa ve bazı mesajları yanlış işlerse, Kafka’nın kalıcılık özelliği sayesinde bu hata düzeltildikten sonra tüketici offset’ini geriye çekerek (rewind) mesajları yeniden işleyebilir. Bu, veri tabanı yedeklerinden geri dönmekten çok daha hızlı ve esnek bir kurtarma mekanizması sunar. Örneğin, gece yapılan bir dağıtım sonrası uygulamanız hatalı veri üretmeye başladıysa, sorunu düzelttikten sonra Kafka’daki olay akışını hatanın başladığı noktadan tekrar oynatarak verilerinizi tutarlı hale getirebilirsiniz.
• Yeni Özellik Geliştirme ve Analiz: Yeni bir uygulama veya özellik geliştirdiğinizde, sistemdeki tüm geçmiş olay akışını alıp bu yeni uygulama üzerinde test edebilir veya analiz edebilirsiniz. Bu, gerçek dünya verileriyle geliştirme yapmanızı ve geçmiş olaylardan yeni içgörüler elde etmenizi sağlar. Örneğin, yeni bir makine öğrenimi modeli eğitecekseniz, geçmiş 3 aylık tüm kullanıcı etkileşim verilerini Kafka’dan alıp modelinizi eğitebilirsiniz.

Bu özellikler, Kafka’yı sadece bir mesaj iletim aracı olmaktan çıkarıp, şirketinizin tüm olay verileri için merkezi, güvenilir ve ölçeklenebilir bir kaynak haline getirir. Bu sayede, işletmeler daha çevik olabilir, gerçek zamanlı kararlar alabilir ve veri odaklı bir kültürü benimseyebilirler. Kafka’nın gerçek gücünü anlamak, modern dağıtık sistem mimarileri için sağlam bir temel oluşturmanın ilk adımıdır.

Vaka Analizleri: Kafka’yı Doğru Kullanan Şirketler Neler Kazandı?

Kafka’nın teorik faydalarını ve bir akış platformu olarak nasıl kullanılması gerektiğini anladık. Şimdi, gerçek dünya senaryolarında Kafka’yı doğru bir şekilde benimseyen şirketlerin elde ettiği somut kazanımlara odaklanalım. Bu vaka analizleri, Kafka’nın iş süreçlerini nasıl dönüştürebileceğini ve rekabet avantajı sağlayabileceğini gösterecektir.

Büyük Veri Analitiği için Gerçek Zamanlı Akışlar: Bir E-ticaret Örneği

Modern e-ticaret platformları, milyonlarca kullanıcı etkileşimi, sipariş, ürün görüntüleme ve sepet değişikliği gibi olaylarla doludur. Bu devasa veri akışını geleneksel yöntemlerle yönetmek ve anlamlandırmak oldukça zordur. Türkiye’deki büyük bir e-ticaret firması olan “HızlıSepet” örneğini ele alalım. HızlıSepet, başlangıçta monolitik bir yapıya ve ilişkisel veritabanlarına bağımlıydı. Ancak artan veri hacmi ve gerçek zamanlı analiz ihtiyacı, onları Kafka’ya yönlendirdi.

Problem: HızlıSepet’in eski sistemi, kullanıcı davranışlarını analiz etmek, kişiselleştirilmiş öneriler sunmak ve stok takibini gerçek zamanlı yapmakta yetersiz kalıyordu. Veritabanı sorguları yavaşlıyor, pazarlama kampanyaları gecikmeli başlatılıyor ve dolandırıcılık tespiti manuel süreçlerle yapılıyordu.

Kafka Çözümü: HızlıSepet, tüm kullanıcı etkileşimlerini (ürün görüntüleme, sepete ekleme, satın alma, favorilere ekleme), sipariş durum güncellemelerini ve stok değişikliklerini Kafka konularına (topics) birer olay olarak göndermeye başladı. Örneğin, bir ürün sepete eklendiğinde, sepet-olaylari konusuna bir mesaj gönderiliyordu.

• Kişiselleştirilmiş Öneriler: Bir tüketici grubu, kullanici-etkilesimleri konusundaki olayları dinleyerek anlık olarak kullanıcı profillerini güncelledi. Bu profiller, Kafka Streams API kullanılarak gerçek zamanlı olarak işlendi ve kullanıcılara özel ürün önerileri sunan bir mikroservise iletildi. Sonuç olarak, öneri motorunun isabetliliği arttı ve dönüşüm oranları %15 yükseldi.
• Sepet Terk Etme Kampanyaları: Başka bir tüketici grubu, sepet-olaylari konusunu izleyerek belirli bir süre içinde sepetinde ürün olup da satın alma yapmayan kullanıcılara otomatik olarak indirim kodları veya hatırlatma e-postaları gönderdi. Bu sayede, sepet terk etme oranlarında %10’luk bir düşüş sağlandı.
• Stok Takibi ve Entegrasyon: Sipariş olayları, anlık olarak stok-guncelleme konusuna iletildi. Stok yönetimi sistemi, bu konuyu dinleyerek stokları anında güncelledi ve diğer departmanlar (örneğin kargo) güncel stok bilgilerine gerçek zamanlı olarak erişebildi. Bu, yanlış stok bilgisi nedeniyle yaşanan iptalleri %5 oranında azalttı.
• Dolandırıcılık Tespiti: Ödeme ve kullanıcı davranış olayları, bir tüketici grubu tarafından işlenerek şüpheli desenler (örneğin, kısa sürede yüksek değerli birden fazla sipariş) anında tespit edildi ve dolandırıcılık ekiplerine uyarı gönderildi. Bu, dolandırıcılık kaynaklı kayıpları önemli ölçüde azalttı.

HızlıSepet, Kafka’yı bir olay akışı platformu olarak kullanarak, veriyi tek bir kaynaktan alıp birden fazla iş akışında eş zamanlı olarak değerlendirme yeteneği kazandı. Bu, operasyonel verimliliği artırmakla kalmadı, aynı zamanda müşteri deneyimini de önemli ölçüde iyileştirdi.

Mikroservis Mimarilerinde Güvenilir İletişim: Bir Finans Uygulaması

Finans sektöründe, veri tutarlılığı ve güvenilirliği hayati öneme sahiptir. “GüvenBank” adında bir dijital bankacılık uygulaması, mikroservis mimarisine geçiş yaparken servisler arası iletişimin karmaşıklığıyla karşılaştı. Geleneksel HTTP tabanlı RESTful API çağrıları, yüksek gecikmeye, bağımlılıklara ve hata durumlarında veri tutarsızlığına yol açıyordu.

Problem: GüvenBank’ın mikroservisleri, para transferleri, hesap güncellemeleri ve işlem geçmişi gibi kritik operasyonlar için birbirlerine senkronize HTTP çağrıları yapıyordu. Bir servis çöktüğünde veya yavaşladığında, tüm zincir etkileniyor, veri tutarsızlıkları oluşuyor ve müşteri deneyimi olumsuz etkileniyordu. Özellikle “para transferi” gibi işlemler, birden fazla servisin (hesap servisi, bildirim servisi, işlem geçmişi servisi) başarılı bir şekilde tamamlanmasını gerektiriyordu.

Kafka Çözümü: GüvenBank, servisler arası iletişimin ana omurgası olarak Kafka’yı benimsedi ve olay tabanlı mimariye (event-driven architecture) geçti. Her önemli iş olayı (örneğin, para-transferi-baslatildi, hesap-bakiye-guncellendi, islem-gecmisi-kaydedildi) Kafka konularına gönderildi.

• Asenkron ve Güvenilir İletişim: Bir kullanıcı para transferi başlattığında, ParaTransferiServisi, para-transferi-baslatildi olayını Kafka’ya gönderdi. Diğer servisler (HesapServisi, BildirimServisi, IslemGecmisiServisi) bu olayı kendi tüketici gruplarıyla dinleyerek kendi iş mantıklarını asenkron ve bağımsız olarak yürüttüler. Bu, servisler arasındaki sıkı bağımlılığı ortadan kaldırdı ve sistemin genel dayanıklılığını artırdı. Bir servis geçici olarak kullanılamaz olsa bile, Kafka’daki olaylar kalıcı olduğu için servis yeniden ayağa kalktığında kaldığı yerden işlemeye devam edebildi.
• Event Sourcing Pattern: GüvenBank, kritik iş süreçlerinde Event Sourcing (Olay Kaynaklama) desenini uyguladı. Hesap bakiyesi gibi kritik verilerin son durumu yerine, tüm hesap hareketleri (para yatırma, çekme, transfer) olay olarak Kafka’da depolandı. Bu sayede, herhangi bir anda bir hesabın bakiyesi, o hesaba ait tüm olayların yeniden oynatılmasıyla (replay) hesaplanabildi. Bu, veri tutarlılığını en üst düzeye çıkardı ve geçmiş durumlara dönme yeteneği sağladı.
• Gerçek Zamanlı Denetim ve Raporlama: Tüm finansal işlemlerin olay akışı olarak Kafka’da bulunması, denetim ekiplerinin gerçek zamanlı olarak işlem geçmişini izlemesine ve uyumsuzlukları anında tespit etmesine olanak tanıdı. Ayrıca, iş zekası (BI) araçları, Kafka’daki olay akışlarını tüketerek anlık finansal raporlar ve gösterge tabloları oluşturabildi.

GüvenBank, Kafka’yı bir akış platformu olarak benimseyerek, mikroservis mimarisinin getirdiği karmaşıklığı yönetmekle kalmadı, aynı zamanda finansal işlemlerin güvenilirliğini, şeffaflığını ve hızını önemli ölçüde artırdı. Bu iki vaka analizi, Kafka’nın farklı sektörlerde nasıl dönüştürücü bir etki yaratabileceğini ve onu doğru bir şekilde kullanmanın işletmelere neler kazandırabileceğini açıkça göstermektedir.

Kafka’yı Sisteminize Doğru Entegre Etmek İçin İpuçları

Kafka’nın bir akış platformu olduğunu ve onu nasıl kullanmanız gerektiğini anladık. Şimdi sıra, bu bilgiyi pratiğe dökmeye ve Kafka’yı sisteminize en verimli şekilde entegre etmek için bazı pratik ipuçlarına geldi. Doğru tasarım ve yapılandırma, Kafka dağıtımınızın performansını, güvenilirliğini ve ölçeklenebilirliğini doğrudan etkileyecektir.

Topic ve Partition Tasarımı Nasıl Yapılmalı?

Kafka’nın temel yapı taşlarından olan konular (topics) ve bölümler (partitions), sisteminizin performansını ve veri dağıtımını doğrudan etkiler. Bu yüzden, doğru bir tasarım yapmak hayati önem taşır.

• Konu Sayısı ve Granülerlik: Her iş olayı türü için ayrı bir konu (topic) oluşturmayı düşünün. Örneğin, siparisler, kullanici-etkilesimleri, stok-guncellemeleri gibi. Bu, olayları mantıksal olarak ayırmanıza ve farklı tüketici gruplarının sadece ilgilendikleri verilere abone olmasına olanak tanır. Aşırı granülerlikten kaçınmakla birlikte, çok genel konular da karmaşıklığa yol açabilir.
• Bölüm Sayısı (Partition Count): Bölüm sayısı, bir konunun yatay ölçeklenebilirliğini belirler. Daha fazla bölüm, daha fazla paralel tüketiciye ve daha yüksek işlem hacmine olanak tanır. Ancak çok fazla bölüm de operasyonel yükü artırabilir ve tüketici grubunun yeniden dengeleme (rebalance) sürelerini uzatabilir.
  • Kural: Bölüm sayısını, beklenen üretici ve tüketici hacmine göre belirleyin. Genellikle, bir tüketici grubundaki tüketici sayısı kadar veya biraz daha fazla bölüm olması idealdir. Her bir bölüm için saniyede 1 MB/s (veya daha fazla) yazma/okuma kapasitesini hedefleyebiliriz. Örneğin, saniyede 100 MB veri işleyecekseniz ve her bölüm 1 MB/s işleyebiliyorsa, en az 100 bölüme ihtiyacınız olacaktır.
  • Deneme: Üretim ortamına yakın test ortamlarında farklı bölüm sayılarını deneyerek en uygun dengeyi bulun.
• Anahtar Seçimi (Key Selection): Üreticiler mesajları Kafka’ya gönderirken bir anahtar (key) belirleyebilirler. Aynı anahtara sahip mesajlar her zaman aynı bölüme gider. Bu, ilgili mesajların sırasını korumak için kritik öneme sahiptir.
  • Tutarlılık İçin: Eğer belirli bir varlıkla ilgili tüm olayların sırasını korumak istiyorsanız (örneğin, bir kullanıcının tüm sipariş olayları), o varlığın kimliğini (örneğin, kullanici_id) anahtar olarak kullanın.
  • Yük Dengeleme İçin: Anahtarların bölümler arasında eşit dağılmasını sağlayacak bir strateji benimseyin. Eğer anahtarlar dengesiz dağılırsa, bazı bölümler aşırı yüklenirken diğerleri boş kalır, bu da performans darboğazlarına yol açar. Eğer mesajların sırası önemli değilse ve maksimum yük dengeleme isteniyorsa, anahtar olarak benzersiz bir UUID kullanmak veya hiç anahtar kullanmamak da bir seçenek olabilir (Kafka bu durumda round-robin dağıtım yapar).
• Çoğaltma Faktörü (Replication Factor): Her bölümün kaç kopyasının tutulacağını belirler. Genellikle üretim ortamlarında 3 çoğaltma faktörü (replication factor) önerilir. Bu, bir veya iki brokerın çökmesi durumunda bile veri kaybı yaşanmamasını sağlar.

Tüketici Grupları ve Offset Yönetimi Nasıl Optimize Edilir?

Tüketicilerin ve offset yönetiminin doğru yapılandırılması, veri tutarlılığı ve işleme verimliliği için hayati öneme sahiptir.

• Tüketici Grubunu Doğru Kullanın: Aynı mantıksal işi yapan tüm tüketicileri tek bir tüketici grubuna dahil edin. Bu, Kafka’nın bölümleri tüketiciler arasında otomatik olarak dengelemesini sağlar. Farklı iş mantıklarına sahip uygulamalar için ayrı tüketici grupları oluşturun.
• Offset Commit Stratejileri: Tüketicilerin okuma konumlarını (offset) ne zaman kaydedeceği (commit edeceği) kritiktir.
  • Otomatik Commit (enable.auto.commit=true): Kolaydır ancak mesaj kaybı veya çift işleme riskini artırabilir. Genellikle düşük öncelikli veya idempotent (aynı işlemin birden fazla kez yapılmasının bir yan etkisi olmayan) işler için uygundur.
  • Manuel Commit (enable.auto.commit=false): Daha fazla kontrol sağlar. Mesajı işledikten ve sonucunu kalıcı bir depoya (veritabanı, başka bir Kafka konusu) yazdıktan sonra offset’i kaydedin. Bu, “en az bir kez” (at-least-once) veya “tam olarak bir kez” (exactly-once) semantiği elde etmek için gereklidir.
  • Toplu Commit (Batch Commit): Belirli sayıda mesaj işlendikten sonra veya belirli bir zaman aralığında offset’i kaydedin. Bu, her mesaj için commit yapmaktan daha verimlidir ancak işlenmemiş bazı mesajların yeniden işlenmesine yol açabilir.
• Hata İşleme ve Yeniden Denemeler (Error Handling and Retries): Bir mesaj işlenirken hata oluşursa ne yapılacağını belirleyin.
  • Yeniden Deneme Konuları (Retry Topics): Hatalı mesajları belirli bir gecikmeyle yeniden denemek için ayrı bir konuya (retry topic) gönderin.
  • Ölü Mesaj Kuyrukları (Dead Letter Queues – DLQ): Belirli sayıda denemeden sonra hala işlenemeyen mesajları, manuel inceleme için ayrı bir “ölü mesaj kuyruğu” konusuna gönderin. Bu, ana tüketici grubunun tıkanmasını engeller.

Güvenlik ve Performans için En İyi Uygulamalar Nelerdir?

Kafka dağıtımınızın güvenliğini sağlamak ve en yüksek performansı elde etmek için aşağıdaki uygulamaları göz önünde bulundurun.

• Güvenlik (Security):
  • Kimlik Doğrulama (Authentication): SASL (Simple Authentication and Security Layer) veya SSL/TLS kullanarak istemcilerin brokerlara kimlik doğrulaması yapmasını sağlayın.
  • Yetkilendirme (Authorization): ACL’ler (Access Control Lists) ile hangi kullanıcının hangi konulara yazma veya okuma iznine sahip olduğunu belirleyin.
  • Şifreleme (Encryption): Brokerlar arası iletişimi ve istemci-broker iletişimini SSL/TLS ile şifreleyin.
• İzleme ve Uyarılar (Monitoring and Alerting): Kafka kümenizin sağlığını ve performansını sürekli olarak izleyin.
  • JMX metriklerini kullanarak broker, üretici ve tüketici metriklerini (örneğin, kuyruk derinliği, gecikme, hata oranları) takip edin.
  • Prometheus ve Grafana gibi araçlarla görselleştirme yapın.
  • Kritik eşikler aşıldığında (örneğin, tüketici gecikmesi belirli bir eşiği aştığında) otomatik uyarılar (alertler) oluşturun.
• Toplu İşleme (Batching): Üreticilerin mesajları tek tek göndermek yerine, belirli sayıda mesajı veya belirli bir boyuta ulaşan mesajları toplu olarak göndermesi performansı artırır. Bu, ağ ve disk I/O yükünü azaltır.
• Sıkıştırma (Compression): Mesajları üretici tarafında sıkıştırarak (örneğin, GZIP, Snappy, LZ4) ağ bant genişliği kullanımını ve disk alanını azaltabilirsiniz. Bu, özellikle yüksek hacimli veri akışlarında önemli bir performans artışı sağlar.
• Donanım ve Ağ Optimizasyonu: Yüksek performanslı diskler (SSD), yeterli RAM ve düşük gecikmeli ağ altyapısı, Kafka kümenizin performansını doğrudan etkiler. Brokerlar arasında hızlı ve güvenilir bir ağ bağlantısı olduğundan emin olun.

Bu ipuçlarını uygulayarak, Kafka’yı sisteminize sadece entegre etmekle kalmayacak, aynı zamanda onu bir akış platformu olarak en verimli ve güvenilir şekilde kullanabileceksiniz. Doğru mimari seçimleri ve operasyonel en iyi uygulamalar, Kafka’nın sunduğu tüm avantajlardan yararlanmanızı sağlayacaktır.

Sonuç: Kafka’nın Potansiyelini Tam Olarak Kullanmak

Bu makale boyunca, Apache Kafka’nın basit bir mesaj kuyruğu olmaktan çok daha fazlası olduğunu ve onu bu şekilde ele almanın sistemlerinize nasıl zarar verebileceğini ayrıntılı olarak inceledik. Kafka, yüksek performanslı, dağıtık ve kalıcı bir olay akışı platformudur. Onun gerçek gücü, olayları kalıcı olarak depolaması, birden fazla bağımsız tüketici grubunun aynı veriyi farklı amaçlar için işlemesine olanak tanıması ve gerçek zamanlı akış işleme yetenekleri sunmasından gelir.

Kafka’yı bir kuyruk gibi kullanmaya çalışmak, veri kaybı riskini artırır, performans darboğazlarına yol açar, ölçeklenebilirlik sorunları yaratır ve operasyonel karmaşıklığı artırır. Oysa, onu bir olay akışı platformu olarak benimsemek, e-ticaretten finansa kadar birçok sektörde şirketlerin büyük veri analitiği, mikroservisler arası güvenilir iletişim ve gerçek zamanlı karar alma yeteneklerini geliştirmesini sağlamıştır.

Doğru topic ve partition tasarımı, dikkatli offset yönetimi, güçlü güvenlik önlemleri ve sürekli izleme, Kafka dağıtımınızın başarılı olmasının anahtarıdır. Bu en iyi uygulamaları benimseyerek, Kafka’nın sunduğu tüm avantajlardan yararlanabilir ve sistemlerinizi geleceğin veri odaklı dünyasına hazırlayabilirsiniz. Unutmayın, Kafka sadece mesajları bir noktadan diğerine taşıyan bir araç değil, aynı zamanda işletmenizin tüm olay verileri için merkezi, güvenilir ve stratejik bir omurgadır. Onun potansiyelini tam olarak anlamak ve kullanmak, modern yazılım mimarilerinin vazgeçilmez bir parçasıdır.

Sıkça Sorulan Sorular (SSS)

Kafka’yı bir kuyruk olarak kullanmak tamamen mi yanlıştır?

Hayır, tamamen yanlış demek yerine, Kafka’nın sunduğu tüm yetenekleri kullanmamak ve onu yanlış bir modelde kullanmak verimsizdir demek daha doğru olur. Eğer tek bir tüketiciye sahip, kısa ömürlü ve tek seferlik işleme gerektiren basit bir senaryonuz varsa, Kafka’yı bir kuyruk gibi kullanabilirsiniz. Ancak bu durumda, geleneksel bir mesaj kuyruğu (örneğin RabbitMQ veya SQS) muhtemelen daha basit ve uygun maliyetli bir çözüm olabilir. Kafka’nın gücü, birden fazla tüketici grubuna, veri kalıcılığına ve akış işleme yeteneklerine ihtiyaç duyduğunuz daha karmaşık, dağıtık ve ölçeklenebilir senaryolarda ortaya çıkar.

Kafka’nın yerine hangi durumlarda geleneksel kuyruklar tercih edilmeli?

Geleneksel mesaj kuyrukları, genellikle aşağıdaki durumlarda Kafka’ya göre daha uygun olabilir:

• Basit İşleme Modelleri: Mesajların tek bir tüketici tarafından bir kez işlenmesi ve ardından silinmesi gereken basit iş akışları.
• Düşük Hacimli Veri: Çok yüksek mesaj hacmi gerektirmeyen durumlar.
• Kısa Ömürlü Mesajlar: Mesajların kalıcı olarak saklanmasına gerek olmayan ve işlendikten hemen sonra kaybolması beklenen senaryolar.
• Sıkı Sıra Garantisi (Global FIFO): Tüm kuyruk genelinde katı bir FIFO (ilk giren ilk çıkar) sırası gerektiren durumlar (Kafka partition bazında sıra garantisi verir).
• Daha Az Operasyonel Yük: Daha az karmaşık bir kurulum ve yönetim gerektiren küçük ölçekli projeler.

Kafka’da mesajların sırası nasıl garanti edilir?

Kafka, bir bölüm (partition) içindeki mesajların sırasını garanti eder. Yani, bir üretici belirli bir bölüme mesajları hangi sırayla gönderdiyse, tüketiciler de o bölümden mesajları aynı sırayla okuyacaktır. Ancak farklı bölümler arasındaki mesajların genel bir sırası garanti edilmez. Eğer mesajların genel sırası kritikse, tüm ilgili mesajları aynı bölüme yönlendirmek için mesaj anahtarını (key) doğru seçmeniz gerekir. Örneğin, bir kullanıcının tüm sipariş olaylarını aynı kullanıcı ID’sini anahtar olarak kullanarak tek bir bölüme göndermek, o kullanıcının siparişlerinin sırasını koruyacaktır.

Bir mesajın yalnızca bir kez işlendiğini nasıl garanti edebiliriz (Exactly-Once Semantics)?

Kafka, varsayılan olarak “en az bir kez” (at-least-once) semantiği sunar, yani bir mesajın birden fazla kez işlenme olasılığı vardır. “Tam olarak bir kez” (exactly-once) semantiğini elde etmek daha karmaşıktır ve hem Kafka’nın kendisinde hem de uygulama kodunuzda belirli yapılandırmalar gerektirir:

• Üretici Tarafında: Üreticilerde idempotent (yan etkisiz) yazma özelliğini etkinleştirerek (enable.idempotence=true), aynı mesajın birden fazla kez gönderilmesi durumunda bile Kafka’nın sadece bir kopyasını kaydetmesini sağlayabilirsiniz.
• Tüketici Tarafında: Tüketicilerin offset’lerini manuel olarak yönetmesi ve mesajları işledikten sonra sonuçları kalıcı bir depoya (örneğin veritabanı) yazarken atomik bir işlem içinde offset’i de kaydetmesi gerekir. Kafka Streams API ve ksqlDB gibi araçlar, bu karmaşıklığı soyutlayarak exactly-once semantiği sunar.

Kafka’da eski mesajlar ne zaman silinir?

Kafka’da mesajlar, belirli bir süre (log.retention.hours veya log.retention.ms) veya belirli bir boyuta (log.retention.bytes) ulaşana kadar kalıcı olarak diskte saklanır. Bu süre veya boyut aşıldığında, en eski mesajlar otomatik olarak silinir. Bu politika, konu (topic) bazında veya küme genelinde yapılandırılabilir. Varsayılan olarak, Kafka mesajları genellikle 7 gün boyunca saklar. İhtiyaçlarınıza göre bu süreyi uzatabilir veya kısaltabilirsiniz.

#Kafka #AkışPlatformu #MesajKuyruğu #DağıtıkSistemler #VeriMimarisi