Cy Logic Insights

Mikro Hizmet Mimarisinde Dağıtık İşlemler: Finans Yazılımlarında Saga Deseni ile Veri Tutarlılığı

Finans ve muhasebe yazılımlarında mikro hizmet mimarisiyle dağıtık işlemlerin yönetimi ve Saga deseni ile veri tutarlılığı sağlama adımları.

Mikro Hizmet Mimarisinde Dağıtık İşlemler: Finans Yazılımlarında Saga Deseni ile Veri Tutarlılığı

Giriş ve Dağıtık Sistemlerin Mimarisi

Modern yazılım geliştirme süreçlerinde monolitik yapılardan mikro hizmet mimarisine geçiş, ölçeklenebilirlik ve esneklik gibi önemli avantajlar sunar. Özellikle çok katmanlı yapıların kurulduğu Finans & Muhasebe Sistemleri süreçlerinde, işlevselliklerin bağımsız servisler halinde ayrılması yaygın bir yaklaşımdır. Ancak bu dağıtık yapı, veri yönetimi açısından geleneksel veritabanı yaklaşımlarını zorlaştırır.

Birden fazla mikro hizmetin kendi veritabanına sahip olduğu senaryolarda, tek bir mantıksal işlem (transaction) birden fazla servisi kapsayabilir. Geleneksel ACID (Atomicity, Consistency, Isolation, Durability) prensiplerini dağıtık ortamlarda iki aşamalı commit (2PC) protokolleri ile çözmek, performans darboğazlarına ve yüksek gecikmelere yol açabilir. Bu noktada dağıtık işlemler ve veri tutarlılığı için alternatif yaklaşımlara ihtiyaç duyulur.

Saga Deseni Nedir ve Nasıl Çalışır?

Saga deseni, dağıtık sistemlerde veri tutarlılığını yönetmek için kullanılan bir tasarım desenidir. Bir işlem zinciri olarak çalışan Saga, her mikro hizmetin kendi yerel veritabanında bir işlem (local transaction) yürütmesini sağlar. Eğer zincirdeki tüm adımlar başarılı bir şekilde tamamlanırsa işlem bütünlüğü korunmuş olur.

Zincir içerisindeki herhangi bir adımda hata oluştuğunda ise Saga deseni devreye girer. Başarıyla tamamlanmış önceki adımların etkilerini tersine çeviren telafi edici işlemler (compensating transactions) tetiklenir. Bu mekanizma, nihai tutarlılık (eventual consistency) ilkesine dayalı olarak çalışır ve finans yazılımları için kritik bir güvence sağlar.

Adım Adım Saga Uygulama Yöntemleri

Saga desenini mimarinize entegre ederken tercih edebileceğiniz iki temel yaklaşım bulunmaktadır:

1. Koreografi Tabanlı Saga (Choreography)

Merkezi bir koordinatörün bulunmadığı bu yöntemde, servisler birbirleriyle olaylar (events) aracılığıyla haberleşir.

  • Her mikro hizmet kendi yerel işlemini tamamlar ve bir olay yayınlar (event publishing).
  • Sonraki servis bu olayı dinler, kendi işlemini gerçekleştirir ve yeni bir olay tetikler.
  • Hata durumunda, ilgili servis bir telafi olayı yayınlar ve diğer servisler bu olayı dinleyerek kendi verilerini geri alır.

2. Orkestrasyon Tabanlı Saga (Orchestration)

Merkezi bir yöneticinin (orchestrator) bulunduğu bu yapıda, tüm iş akışı tek bir bileşen tarafından kontrol edilir.

  • Orkestratör servis, diğer servislere komutlar gönderir.
  • Gelen yanıtlara göre sonraki adımı belirler veya hata durumunda telafi komutlarını sırasıyla tetikler.
  • Karmaşık iş akışlarında durum yönetimi ve izlenebilirlik açısından daha kontrollü bir süreç sunar.

Finansal Süreçlerde Uygulama ve Dikkat Edilmesi Gerekenler

Finans & Muhasebe Sistemleri gibi hassas alanlarda veri tutarlılığı hayati önem taşır. Para transferi, faturalandırma veya stok düşümü gibi senaryolarda:

  • Telafi edici işlemlerin idempotent (aynı istek tekrarlandığında aynı sonucu veren) tasarlanması şarttır.
  • Ağ kopmaları veya servis kesintilerine karşı mesaj kuyruklarının dayanıklı yapılandırılması gerekir.
  • İşlem durumlarının anlık olarak izlenebilmesi için merkezi loglama ve takip mekanizmaları kurulmalıdır.

Sonuç

Mikro hizmet mimarilerinde dağıtık işlemlerin yönetimi, doğru desenler seçilmediğinde sistem kararsızlığına yol açabilir. Saga deseni, iki aşamalı commit maliyetlerinden kaçınarak finans yazılımlarında esnek ve güvenilir bir veri tutarlılığı sağlar.

Varsayımsal Bir Finans Senaryosu Üzerinden Çalışma

Saga deseninin pratikte nasıl çalıştığını somutlaştırmak için çok uluslu bir para transferi ve kur dönüşüm senaryosunu ele alalım. Kullanıcı, kaynak hesaptan hedef hesaba döviz transferi başlattığında üç ayrı mikro hizmet devreye girer: Hesap Bakiye Servisi, Döviz Çevrim Servis ve Muhasebe Kayıt Servisi. İlk adımda Hesap Bakiye Servisi, kullanıcının yerel veritabanından tutarı düşer ve başarı mesajı üretir. İkinci adımda Döviz Çevrim Servisi güncel kurlarla dönüşümü yapar ancak üçüncü adım olan Muhasebe Kayıt Servisi aşamasında beklenmeyen bir veritabanı zaman aşımı hatası meydana gelir. Bu senaryoda geleneksel kilitlenme mekanizmaları yerine nihai tutarlılık prensibi çalıştırılır. Orkestratör servis hata sinyalini algıladığı anda telafi süreçlerini başlatır. Döviz çevrimi iptal edilir ve ilk adımda hesaptan düşülen tutar, Hesap Bakiye Servisi tarafından telafi işlemi (compensating transaction) ile kullanıcıya iade edilir. Bu süreçte dikkat edilmesi gereken en büyük mimari trade-off, anlık tutarlılıktan ödün verilerek sistemin erişilebilirliğinin (availability) artırılmasıdır. Kullanıcı arayüzünde işlemin beklemede olduğu bilgisi şeffaf bir şekilde paylaşılmalıdır.

Gerçekleştirim ve Hata Yönetimi Kontrol Listesi

Dağıtık bir finans mimarisinde Saga desenini canlı ortama alırken göz önünde bulundurulması gereken kritik maddeler bulunmaktadır. İlk olarak, tüm telafi edici işlemler ve komutlar kesinlikle idempotent (tekrarlanabilir) tasarlanmalıdır. Ağ kesintileri nedeniyle aynı mesajın iki kez iletilmesi durumunda, bakiye düşme veya iade etme işlemlerinin mükerrer çalışmasını engellemek için benzersiz işlem anahtarları (idempotency keys) kullanılmalıdır. İkinci olarak, mesaj kuyruklarında (Message Broker) yaşanabilecek ölü mektup kuyruğu (Dead Letter Queue) senaryoları önceden planlanmalı ve manuel müdahale gerektiren istisnai durumlar için alarm mekanizmaları kurulmalıdır. Üçüncü olarak, Finans & Muhasebe Sistemleri entegrasyonlarında denetlenebilirlik (auditability) şarttır; bu nedenle her bir Saga adımının durumu, zaman damgası ve hata logları merkezi bir loglama altyapısında depolanmalıdır. Son aşamada ise sistem yük testlerine tabi tutularak, yüksek trafik altında orkestratör servislerin darboğaz oluşturup oluşturmadığı ve telafi işlemlerinin gecikme süreleri detaylıca analiz edilmelidir.

Kaynaklar