Mikro Hizmet Mimarisinde Dağıtık İşlemler ve Veri Tutarlılığı

Giriş ve Mimari Dönüşüm

Kurumsal yapılar, iş süreçlerini ölçeklenebilir kılmak adına monolitik yapılardan mikro hizmet mimarisi yaklaşımına geçiş yapmaktadır. Özellikle Finans & Muhasebe Sistemleri gibi kritik modüllerin ayrıştırılması, hata izolasyonu sağlarken dağıtık işlemler (distributed transactions) bağlamında yeni teknik zorlukları da beraberinde getirir.

Dağıtık İşlemlerde Temel Zorluklar

Mikro hizmet mimarisi içinde her servisin kendine ait veri tabanı bulunması, geleneksel ACID prensiplerinin tek bir işlem (transaction) sınırında çalışmasını engeller. Bir ödeme emri verildiğinde, hem ana muhasebe defterinin güncellenmesi hem de ilgili cari hesabın bakiyesinin düşülmesi gerekir. Bu süreçlerin farklı servisler arasında koordine edilmesi, veri tutarlılığı ihlallerine açık hale gelir.

İki Aşamalı Commit (2PC) Protokolü

Dağıtık sistemlerde atomikliğin korunması için kullanılan klasik yöntemlerden biri iki aşamalı commit mekanizmasıdır. Bu protokol iki fazdan oluşur:

• Hazırlık Fazı (Prepare Phase): Koordinatör servis, tüm katılımcı servislere işlemin tamamlanıp tamamlanamayacağını sorar. Katılımcılar kaynakları kilitleyip hazır olduklarını bildirir.
• Commit Fazı: Tüm servislerden onay gelirse işlem kalıcı hale getirilir; aksi takdirde tüm değişiklikler geri alınır (rollback).

2PC Dezavantajları

Finans yazılımları yüksek eşzamanlılık gerektirir. 2PC protokolü, kilitlenme (locking) süreleri ve ağ gecikmeleri nedeniyle sistem genelinde performans darboğazlarına yol açabilir. Koordinatör servisin çökmesi durumunda ise katılımcı servislerin kilitli kalması büyük bir risk unsuru oluşturur.

Outbox Deseni ile Asenkron Yaklaşım

Outbox deseni, iki aşamalı commit protokolünün getirdiği kilitlenme maliyetlerini ortadan kaldırmak için tasarlanmış asenkron bir çözümdür. Bu modelde, ana veri tabanı işlemi ile dışarıya fırlatılacak olay (event) aynı yerel işlem içinde outbox tablosuna yazılır.

Outbox Çalışma Adımları

1. Yerel İşlem: Servis, kendi veri tabanında iş kuralını uygular ve aynı transaction içinde outbox tablosuna bir mesaj kaydı atar.
2. Olay İletimi: Ayrı bir işlem (arka plan tarayıcısı veya CDC - Change Data Capture aracı), outbox tablosundaki okunmamış kayıtları okuyarak mesaj kuyruğuna (Message Broker) iletir.
3. Temizlik: Başarıyla iletilen mesajlar outbox tablosundan silinir veya işaretlenir.

Doğru Yaklaşımın Seçimi

Dağıtık işlemler tasarlanırken, sistemin iş gereksinimleri titizlikle analiz edilmelidir. Kesin zamanlı senkronizasyon gerektiren dar alanlarda kuralcı protokoller değerlendirilirken, performansın ve ölçeklenebilirliğin ön planda olduğu finans yazılımları projelerinde nihai tutarlılık (eventual consistency) sağlayan outbox deseni daha güvenli bir alternatif sunar.

Varsayımsal Çalışma Örneği: E-Ticaret Ödeme Akışı

Senaryomuzda, bir müşterinin Finans & Muhasebe Sistemleri altyapısına entegre edilmiş bir sipariş modülü üzerinden ödeme yaptığını varsayalım. Sipariş servisi, siparişi oluşturduktan sonra ödeme servisine bir istek atar ve muhasebe servisi de gelir kaydını işler. Bu süreçte Outbox deseni kullanılarak veritabanı kilitlenmelerinin önüne geçilir. Sipariş servisi, sipariş tablosuna veri yazarken aynı işlem bloğu içinde Outbox tablosuna da bir 'SiparişOluşturuldu' olayı ekler. Arka planda çalışan bir Change Data Capture (CDC) mekanizması, bu tabloyu sürekli tarayarak yeni kayıtları Kafka veya RabbitMQ gibi bir mesaj kuyruğuna aktarır. Ödeme servisi bu mesajı tüketerek kendi bakiye düşme işlemini gerçekleştirir. Eğer ödeme servisi geçici olarak erişilemez duruma gelirse, mesaj kuyruğunda bekleyen veri sistemi kilitlemez; bunun yerine kuyruk mekanizması yeniden deneme (retry) politikalarını devreye sokar. Böylece sistem, anlık ağ kesintilerine veya servis duruşlarına karşı direnç kazanırken, nihai tutarlılık prensibi gereği tüm servisler verinin güncel haline senkronize bir şekilde ulaşmış olur. Bu mimari, operasyonel yükü artırsa da yüksek trafik altında bile sistemin yanıt süresini optimize eder.

Detaylı Uygulama Kontrol Listesi ve Hata Yönetimi

Dağıtık mimarilerde kararlı bir yapı kurmak için belirli mühendislik adımlarının eksiksiz uygulanması şarttır. İlk olarak, veritabanı işlemlerinde Idempotency (tekrarlanabilirlik) mekanizması mutlaka tasarlanmalıdır. Mesaj kuyruklarından aynı olayın birden fazla kez gelme ihtimaline karşı, işlenen her işlemin benzersiz bir anahtar ile kontrol edilmesi gerekir. İkinci olarak, Outbox tablosundan okunan mesajların kuyruğa iletildikten sonra güvenli bir şekilde silinmesi veya 'işlendi' olarak işaretlenmesi veri tekrarını önler. Hata yönetimi aşamasında, Dead Letter Queue (DLQ) yapısı kurulmalı; ardışık denemelerde başarısız olan mesajlar burada toplanarak manuel incelemeye tabi tutulmalıdır. Sistem yöneticileri, finans yazılımları için kritik olan bu süreçlerde gecikme sürelerini ve kuyruk boyutlarını anlık olarak izlemelidir. Ayrıca, telafi edici işlemler (compensating transactions) için SAGA deseninin uygulanabilirliği değerlendirilmeli, ağ bölünmeleri (network partition) ve zaman aşımı senaryoları için devre kesici (circuit breaker) kütüphaneleri entegre edilmelidir. Bu kontrol listesi, dağıtık işlemler sırasında veri kaybetme riskini minimuma indirir.

Kaynaklar

• Finans & Muhasebe Sistemleri — Cy Logic Software