Mikro Hizmet Tabanlı Finans Yazılımlarında Dağıtık İşlemler ve İki Aşamalı Commit Stratejileri

Giriş ve Mimari Dönüşüm

Modern işletmelerin teknolojik altyapılarını dönüştürmesiyle birlikte, monolitik yapılardan mikro hizmet mimarilerine geçiş hız kazanmıştır. Özellikle Finans & Muhasebe Sistemleri gibi kritik operasyonel süreçleri barındıran finans yazılımları, bu dönüşümün merkezinde yer alır. Dağıtık sistem yapısı, ölçeklenebilirlik ve esneklik sağlarken, beraberinde karmaşık teknik zorlukları da getirmektedir.

Bu zorlukların başında, farklı servisler arasında bölünen verilerin senkronizasyonu gelir. Geleneksel veritabanı yönetim sistemlerindeki ACID (Atomicity, Consistency, Isolation, Durability) garantileri, ağ üzerinde koşan bağımsız mikro hizmetler söz konusu olduğunda otomatik olarak sağlanamaz. Bu durum, mimari düzeyde yeni stratejilerin benimsenmesini zorunlu kılar.

Dağıtık İşlemler ve Veri Tutarlılığı Zorlukları

Mikro hizmetler dünyasında her servis kendi veritabanına sahip olma eğilimindedir. Örneğin, bir borçlandırma işlemi ile tahsilat kaydının farklı servisler tarafından işlendiği senaryolarda, ağ gecikmeleri veya anlık bağlantı kopmaları ciddi anormalliklere yol açabilir.

• Kısmi Başarı Durumu: Bir iş akışının ilk adımı başarıyla tamamlanıp veritabanına işlenirken, ikinci adımın ağ hatası nedeniyle başarısız olması.
• Eşzamanlılık Problemleri: Aynı anda gelen finansal isteklerin farklı servislerde farklı sıra ile işlenmesi sonucu oluşan çelişkiler.

Bu gibi senaryolarda veri tutarlılığı, sistemin güvenilirliği açısından hayati önem taşır. Geleneksel kilitlenme (locking) mekanizmaları dağıtık ortamlarda performans darboğazlarına yol açtığı için, alternatif protokoller değerlendirilmelidir.

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

Dağıtık işlemlerde atomikliğin korunması için en bilinen yaklaşımlardan biri iki aşamalı commit (Two-Phase Commit - 2PC) protokolüdür. Bu protokol, işlemin tüm katılımcı servisler tarafından onaylanmasını veya ortaklaşa iptal edilmesini sağlar.

1. Hazırlık Aşaması (Prepare Phase)

Koordinatör servis, tüm katılımcı servislere işlemin gerçekleştirilmeye hazır olup olmadıklarını sorar. Katılımcılar yerel kaynaklarını kilitler, durumu loglar ve hazır olduklarına dair koordinatöre olumlu ya da olumsuz oy bildirir.

2. Commit (Uygulama) Aşaması

Eğer tüm katılımcılar hazırlık aşamasında olumlu yanıt verdiyse, koordinatör herkesin işlemi kalıcı hale getirmesini (commit) emreder. Herhangi bir katılımcıdan olumsuz yanıt gelmesi veya zaman aşımı yaşanması durumunda ise koordinatör tüm servislere işlemi geri alması (rollback) talimatını iletir.

Alternatif Yaklaşımlar ve Telafi Edici İşlemler

İki aşamalı commit protokolü güçlü bir tutarlılık sağlasa da, sıkı kilitlenme mekanizmaları nedeniyle sistem performansını düşürebilir ve ağ gecikmelerine karşı hassastır. Bu nedenle, özellikle yoğun işlem hacmine sahip modern finans yazılımları için farklı modeller de tercih edilmektedir:

• Saga Deseni: Uzun süren dağıtık işlemleri bir dizi yerel adıma bölen ve her adım için tersine çalıştırılabilir bir telafi edici işlem (compensating transaction) tanımlayan yaklaşımdır. Bir adım başarısız olduğunda, geriye dönük telafi adımları sırayla tetiklenir.
• Nihai Tutarlılık (Eventual Consistency): Anlık kilitler yerine olay tabanlı mimariler (Event-Driven Architecture) kullanılarak verinin belirli bir süre zarfında tüm servislerde eşitlenmesi sağlanır.

Sonuç

Mikro hizmet mimarisine geçiş yapan finans ve muhasebe yapılarında, dağıtık işlemlerin yönetimi ve veri bütünlüğünün korunması titiz bir mühendislik çalışması gerektirir. İki aşamalı commit stratejileri ve Saga gibi alternatif modeller, işletmelerin ihtiyaçlarına ve performans kriterlerine göre dikkatle seçilmelidir.

Varsayımsal Örnek Senaryo ve İş Akışı

Bu teorik mimari yaklaşımı somutlaştırmak adına, uluslararası para transferi ve kur dönüşümü gerçekleştiren bir finans modülünü ele alalım. Kullanıcı X, yerel para biriminden döviz hesabına bütçe aktarmak istediğinde, istek API Gateway üzerinden iki bağımsız mikro hizmete yönlendirilir: Kaynak hesap yönetim servisi ve hedef döviz cüzdan servisi. İşlem başladığında koordinatör rolünü üstlenen ana servis, iki katılımcı birime de hazırlık çağrısı gönderir. Kaynak servis bakiye blokesini gerçekleştirip hazır sinyali verirken, hedef servis anlık bir ağ kesintisi veya veritabanı kilitlenmesi nedeniyle zaman aşımına uğrar. Bu durumda koordinatör, tüm katılımcılara iptal komutu iletmek zorundadır. Eğer klasik kilitlenme stratejileri aşırı uzun sürerse, sistem kilitte kalabilir ve kullanıcı bakiyeleri tutarsız görünebilir. Bu tür senaryolarda karşılaşılan en büyük ödünleşme, güçlü veri tutarlılığı ile sistemin genel erişilebilirliği (availability) arasındadır. Sıkı kilit mekanizmaları veriyi korurken yanıt sürelerini uzatır; gevşek modeller ise performansı artırıp çakışma riskini yükseltir.

Uygulama Kontrol Listesi ve Hata Yönetimi

Mikro hizmet tabanlı finans sistemlerinde dağıtık işlem mimarisini canlıya alırken belirli mühendislik standartlarına uyulmalıdır. İlk olarak, ağ bölümlenmesi (network partition) ve koordinatör çökmesi gibi senaryolar için zaman aşımı (timeout) süreleri hassas bir şekilde konfigüre edilmelidir. Katılımcı servislerin yanıt vermediği durumlarda sistemin belirsiz bir durumda (in-doubt state) sonsuza kadar kalmasını engellemek amacıyla otomatik telafi mekanizmaları devreye sokulmalıdır. İkinci olarak, tüm dağıtık işlem adımları merkezi bir loglama ve dağıtık izleme (distributed tracing) altyapısı ile izlenmeli, her bir adımın benzersiz işlem ID'leri ile eşleştirilmesi sağlanmalıdır. Hata yönetimi aşamasında, veritabanı bağlantı kopmaları ve deadlock istisnaları için üstel artan yeniden deneme (exponential backoff) politikaları uygulanmalıdır. Ancak finansal veri bütünlüğünü korumak adına, idempotent (tekrarlanabilir) tasarım prensiplerinden ödün verilmemelidir. Böylece aynı istek yanlışlıkla birden fazla kez tetiklense bile bakiyeler mükerrer işleme maruz kalmaz.

Kaynaklar

• Finans & Muhasebe Sistemleri — Cy Logic Software