Etkinlik Odaklı Mimarinin Gücü: Kafka ile Asenkron Sistemlere Geçiş

Geçtiğimiz hafta sabaha karşı saat 02.00’de aniden çalan pager’ın ardından LogiFlow’daki ekiplerin yaşadığı kâbus, aslında basit bir bellek sızıntısından çok daha derindi. Faturalama servisi olarak adlandırılan bileşen, PDF oluşturma kütüphanesindeki bellek sızıntısı nedeniyle çökmüştü. Ancak zincirleme reaksiyon bununla da kalmadı: rota yönetimi, takip ve hatta müşteri portalı servisleri de arka arkaya devre dışı kaldı. Tüm sistem, tek bir servisin başarısızlığı nedeniyle domino taşları gibi yıkılmıştı.

3 AM’deki Gerçek: Senkron Bağlantıların Tehlikesi

Defne, anında durumu anlamıştı. "Rota yönetimi servisi, faturalama servisinin çalışıp çalışmadığını neden umursuyor?" diye sordu. Emre’nin cevabı, aslında tüm sorunun kaynağını ortaya koyuyordu: Yapay zeka destekli sistemler, her rota hesaplamasının ardından faturalama servisini senkron olarak çağırmıştı. Bu bağlantılar, servisler arasında sıkı bir bağımlılık zinciri oluşturmuştu. Bir bileşenin çökmesi, diğer tüm bileşenleri de peşinden sürüklemişti.

Olay Odaklı Mimarinin Yeniden Keşfi: Kafka’nın Rolü

LogiFlow’un kurtuluşu, olay odaklı mimariye geçişle başladı. Artık servisler, birbirlerine doğrudan HTTP çağrıları yapmak yerine, Kafka aracılığıyla yayınlanan olayları dinliyorlar. Rota yönetimi servisi, her yeni rota hesaplandığında bir RouteCalculated olayı yayınlıyor. Faturalama servisi ise bu olayı dinleyerek, ilgili faturaları bağımsız olarak oluşturuyor. Eğer faturalama servisi geçici olarak durursa, olaylar Kafka’da birikir ve servis normale döndüğünde işlenmeye devam eder. Artık zincirleme çöküşler yok.

Senkron vs Asenkron: Temel Farklar

Aşağıdaki karşılaştırma, iki mimari yaklaşım arasındaki temel farkları özetliyor:

• Senkron (HTTP) Yaklaşımı
• Çağıran servis, yanıtı bekler.
• Bir servisin çökmesi, diğer tüm servisleri de etkiler.
• Servisler arasında sıkı bağlılık söz konusudur.
• İki servis için basit olabilir, ancak on servis için yönetimi zorlaşır.

• Asenkron (Olay Odaklı) Yaklaşım
• Çağıran servis, yanıtı beklemez; olay yayınlanır ve unutulur.
• Bir servisin çökmesi, diğer servisleri doğrudan etkilemez.
• Servisler arasında gevşek bağlılık sağlanır.
• Olay şeması tasarımı gerektirir, ancak geniş ölçekli sistemler için zorunludur.

Kritik Dersler: LogiFlow’dan Alınan Notlar

LogiFlow’un yaşadığı bu deneyimden çıkarılan ana dersler şunlardır:

• Gevşek Bağlılık: Servisler, birbirlerinin yanıtlarını beklememeli. Olaylar aracılığıyla iletişim kurulmalıdır.

• Alan Olayları: RouteCalculated, InvoiceGenerated gibi olaylar, servisler arasında güvenilir bir iletişim kanalı oluşturur. Bu olaylar, sistemdeki değişiklikleri temsil eder ve servislerin birbirlerinden bağımsız olarak gelişmesine olanak tanır.

• Ölü İleti Kuyruğu: Başarısız olan olaylar, kaybolmamalı. Ayrı bir kuyruğa alınarak incelenmeli ve yeniden işlenebilmelidir. Bu sayede veri kaybı önlenir ve sistem güvenilirliği artırılır.

Geleceğe Yönelik Strateji: Olay Odaklı Mimarinin Avantajları

Olay odaklı mimariye geçiş, yalnızca LogiFlow için değil, tüm modern sistemler için kritik bir adımdır. Özellikle microservis mimarilerinde sıkça karşılaşılan senkron çağrıların getirdiği riskleri ortadan kaldırır. Bu yaklaşım, sistemlerin daha dayanıklı, ölçeklenebilir ve yönetilebilir olmasını sağlar. Gelecekteki bölümlerde, teknik borç yönetimi ve sistem performansının iyileştirilmesi gibi konular da ele alınacak. Ancak temelde, olay odaklı mimari, modern yazılım mühendisliğinin vazgeçilmez bir parçası olarak yerini alıyor.