Sigortacılıkta mikroservis mimarisi: ne zaman, nasıl uygulanır?

Sigortacılıkta mikroservis mimarisi, poliçe, hasar, tahsilat, ürün tanımı ve dış entegrasyonlar gibi iş alanlarının her birinin kendi verisine sahip, bağımsız geliştirilen ve bağımsız yayına alınan küçük servisler olarak tasarlanması demektir. Doğru zamanda ve doğru sınırlarla uygulandığında yeni ürünlerin pazara çıkışını hızlandırır, acente portalı veya bankasürans gibi yoğun kanalların ayrı ayrı ölçeklenmesini sağlar.

Yanlış zamanda uygulandığında ise tek bir monolitin sorunlarını onlarca servise dağıtır: dağıtık işlem hataları, izlenemeyen veri akışları ve büyüyen operasyon yükü ortaya çıkar. Bu rehber, bir sigorta şirketinin mikroservise ne zaman geçmesi gerektiğini, servis sınırlarının nasıl çizileceğini ve geçişin hangi adımlarla yönetileceğini ele alıyor.

Mikroservis mimarisi nedir, monolitten farkı ne?

Mikroservis mimarisi, bir uygulamayı ağ üzerinden haberleşen, her biri tek bir iş yeteneğinden sorumlu servislere bölen yazılım mimarisidir. Monolitte ise tüm modüller tek bir kod tabanında, tek bir veritabanı üzerinde ve tek parça olarak yayına alınır.

Türkiye'deki pek çok sigorta şirketinin çekirdek (core) sistemi, yıllar içinde büyümüş bir monolittir. Bu sistemler genellikle güvenilirdir; ancak trafik sigortası tarifesindeki küçük bir değişiklik bile tüm uygulamanın test edilmesini ve toplu yayına alınmasını gerektirebilir. İkisinin arasında bir de modüler monolit seçeneği vardır: tek bir dağıtım birimi olarak kalır, fakat içeride modüller net sınırlarla ayrılır ve birbirinin tablolarına doğrudan erişmez.

Sigorta şirketi hangi durumda mikroservise geçmeli?

Kısa cevap: birden fazla ekip aynı sistem üzerinde birbirini bekler hale geldiğinde ve farklı iş alanlarının farklı hızda değişmesi gerektiğinde. Mikroservis bir hedef değil, belirli organizasyonel ve teknik sorunlara verilen bir cevaptır.

Mikroservise geçişi haklı çıkaran tipik işaretler şunlardır:

• Ürün ve tarife değişiklikleri, hasar veya muhasebe modülündeki yayın takvimini beklemek zorunda kalıyor.
• Acente portalı, karşılaştırma platformları ve bankasürans kanalından gelen teklif trafiği, tüm sistemi aynı anda ölçeklemeyi gerektiriyor.
• Birden fazla geliştirme ekibi aynı kod tabanında çalışıyor ve birleştirme çatışmaları olağan hale geldi.
• Yeni dijital kanallar için core sisteme her seferinde özel uç noktalar yazılıyor.
• Bir modüldeki hata, ilgisiz süreçleri de durduruyor.

Buna karşılık şu durumlarda mikroservise geçmek genellikle erkendir: geliştirme ekibi tek bir takımdan oluşuyorsa, otomatik test ve sürekli entegrasyon (CI/CD) altyapısı yoksa, izleme ve kayıt yönetimi olgun değilse ya da iş alanlarının sınırları henüz netleşmemişse. Bu durumda önce modüler monolit kurmak, sınırları doğrulamak ve daha sonra gerçekten ayrılması gereken modülleri servise dönüştürmek daha düşük riskli bir yoldur.

Sigorta alanında servis sınırları nasıl çizilir?

Servis sınırları teknik katmanlara göre değil, iş yeteneklerine göre çizilmelidir. Alan güdümlü tasarımdaki (Domain-Driven Design, DDD) sınırlı bağlam (bounded context) kavramı burada en kullanışlı araçtır: her bağlam kendi terimlerini, kurallarını ve verisini yönetir.

Sigortacılıkta sık karşılaşılan servis adayları şöyle sıralanabilir:

• Ürün ve tarife servisi: Ürün tanımları, teminatlar, kurallar ve tarife versiyonları.
• Teklif ve fiyatlama servisi: Risk bilgisinin alınması, prim hesaplaması ve teklif yaşam döngüsü.
• Poliçe servisi: Tanzim, zeyil, iptal ve yenileme işlemleri; poliçenin hukuki kaydı.
• Tahsilat servisi: Taksit planları, ödeme kanalları, iade ve mutabakat.
• Hasar servisi: İhbar, dosya yönetimi, eksper atama, rezerv ve ödeme.
• Müşteri ve partner servisi: Sigortalı, sigorta ettiren, acente ve komisyon yapısı.
• Dış entegrasyon servisi: SBM, TRAMER ve diğer kurumsal servislere bağlantı.
• Doküman ve bildirim servisi: Poliçe basımı, e-posta, SMS ve dijital imza süreçleri.

Dış entegrasyonları ayrı bir servis altında toplamak özellikle önemlidir. SBM ve TRAMER entegrasyonu gibi kritik bağlantılar tek bir yerde yönetildiğinde zaman aşımı, yeniden deneme ve kayıt politikaları tutarlı hale gelir.

Sık yapılan hata, servisleri çok küçük bölmektir. "Teminat servisi", "muafiyet servisi" ve "limit servisi" gibi ayrımlar, tek bir teklif hesaplaması için onlarca ağ çağrısı üretir. Bir servis, bir ekibin sahiplenebileceği ve tek başına anlam taşıyan bir iş yeteneği kadar büyük olmalıdır.

Veri tutarlılığı ve poliçe işlemleri nasıl yönetilir?

Mikroservislerde tek bir veritabanı işlemiyle (transaction) tüm adımları garanti etmek mümkün değildir; tutarlılık, olaylar ve telafi adımlarıyla sağlanır. Bu, sigortacılık gibi mali kayıtların kritik olduğu bir alanda en dikkatli tasarlanması gereken konudur.

Bir poliçe tanzimi genellikle şu adımları içerir: teklifin onaylanması, poliçe numarasının üretilmesi, SBM'ye bildirim, tahsilatın başlatılması ve dokümanın üretilmesi. Bu adımlar farklı servislerde gerçekleştiğinde kullanılan başlıca desenler şunlardır:

• Saga deseni: Uzun süren iş akışını adımlara böler; bir adım başarısız olursa önceki adımlar için telafi işlemleri çalıştırılır. Örneğin tahsilat reddedilirse poliçe taslak durumuna geri alınır.
• Giden kutusu (transactional outbox): Servis, kendi verisini güncellediği aynı işlemde yayınlanacak olayı da kaydeder; olay daha sonra güvenilir şekilde mesaj kuyruğuna aktarılır. Böylece "veri güncellendi ama olay kayboldu" durumu önlenir.
• Idempotency (tekrar güvenliği): Aynı istek iki kez gelse bile sonuç değişmemelidir. Acente ekranında çift tıklama ya da ağ kesintisi sonrası tekrar deneme, çift poliçe veya çift tahsilat üretmemelidir.
• Olay güdümlü mimari: "Poliçe tanzim edildi", "hasar ihbar edildi" gibi iş olayları yayınlanır; raporlama, bildirim ve analitik servisleri bu olayları dinleyerek kendi verilerini günceller.

Raporlama ve muhasebe tarafında ise olayların bir veri platformunda toplanması, her servisin veritabanına ayrı ayrı sorgu atılmasından çok daha sağlıklıdır.

Mevcut core sistemden mikroservise geçiş adım adım nasıl yapılır?

En güvenli yöntem, eski sistemi tek seferde değiştirmek yerine "boğucu incir" (strangler fig) deseniyle parça parça devralmaktır. Yeni servisler eski sistemin önüne yerleştirilir, trafik kademeli olarak yeni yapıya yönlendirilir ve eski modüller zamanla devreden çıkarılır.

1. Mevcut durumu haritalayın: Core sistemin modüllerini, veri bağımlılıklarını, toplu işlerini (batch) ve dış entegrasyonlarını çıkarın.
2. İş alanlarını ve sınırları tanımlayın: İş birimleriyle birlikte sınırlı bağlamları belirleyin; hangi verinin hangi alana ait olduğunu netleştirin.
3. Önce bir API katmanı kurun: Kanallar core sisteme doğrudan değil, bir API ağ geçidi (API gateway) üzerinden erişsin. Bu katman, arkadaki değişikliği kanallardan gizler.
4. Düşük riskli ama yüksek değerli bir alanla başlayın: Teklif ve fiyatlama ya da doküman üretimi gibi, hukuki kayıt üretmeyen alanlar iyi ilk adaylardır.
5. Veri senkronizasyonunu kurun: Geçiş döneminde eski ve yeni sistem arasında değişiklik verisi yakalama (Change Data Capture, CDC) veya olay tabanlı senkronizasyon kullanın.
6. Paralel çalıştırın ve karşılaştırın: Yeni servisin ürettiği sonucu, bir süre eski sistemin sonucuyla karşılaştırarak doğrulayın.
7. Trafiği kademeli yönlendirin: Önce tek bir ürün veya kanal, sonra tüm portföy.
8. Eski modülü emekliye ayırın: Devralınan işlevi core sistemden kaldırın ve bağımlılıkları temizleyin.

Bu yaklaşımın ayrıntıları için eski core sigorta sistemlerinin modernizasyonu rehberine bakabilirsiniz.

Mikroservis mimarisinin operasyonel gereksinimleri nelerdir?

Mikroservis, geliştirmeyi kolaylaştırırken operasyonu zorlaştırır; bu yüzden altyapı hazırlığı mimari kararın ayrılmaz parçasıdır. Aşağıdaki yetenekler olmadan mikroservise geçmek, sorunları görünmez hale getirir.

• Gözlemlenebilirlik: Merkezi kayıt (log), metrik ve dağıtık izleme (distributed tracing). Bir teklif isteğinin hangi servislerden geçtiğini tek bir iz numarasıyla takip edebilmek gerekir.
• CI/CD ve otomatik test: Her servis bağımsız yayına alınabilmeli; sözleşme testleri (contract testing) servisler arası uyumu korumalıdır.
• Konteyner ve orkestrasyon: Kubernetes gibi platformlar ölçeklenmeyi ve yeniden başlatmayı yönetir. Bu platformun şirket içinde mi, bulutta mı çalışacağı ayrı bir karardır; bu konuyu sigorta şirketleri için bulut dönüşümü yazısında ele alıyoruz.
• Güvenlik: Servisler arası kimlik doğrulama, gizli bilgi (secret) yönetimi ve kişisel verilerin yalnızca ihtiyaç duyan servislerde tutulması KVKK uyumu açısından belirleyicidir.
• Denetim izi: Poliçe ve hasar üzerindeki her değişikliğin kim tarafından, ne zaman, hangi servis üzerinden yapıldığı kayıt altına alınmalıdır.
• API yönetimi: Versiyonlama, oran sınırlama ve dokümantasyon; ayrıntılar için sigortacılıkta API entegrasyonu rehberine göz atabilirsiniz.

ProdayTech olarak sigorta projelerinde mimari kararı teknoloji tercihinden önce ekip yapısı, yayın sıklığı ve operasyon olgunluğu üzerinden değerlendirmeyi tercih ediyoruz; çünkü aynı mimari, farklı organizasyonlarda çok farklı sonuç verebiliyor.

Mikroservis kararı için kontrol listesi

Aşağıdaki sorulara verilen cevapların çoğu "evet" değilse, önce modüler monolit ve altyapı hazırlığıyla başlamak daha doğrudur.

• Birden fazla ekip, farklı iş alanlarında bağımsız çalışacak mı?
• İş alanlarının sınırları iş birimleriyle birlikte tanımlandı mı?
• Otomatik test kapsamı ve CI/CD hattı mevcut mu?
• Merkezi kayıt, metrik ve dağıtık izleme altyapısı hazır mı?
• Dağıtık işlem desenleri (saga, outbox, idempotency) için ekipte deneyim var mı?
• SBM ve diğer dış entegrasyonlar tek bir katmanda toplanacak mı?
• Raporlama ve muhasebe için olay tabanlı bir veri akışı planlandı mı?
• Geçiş dönemi için eski ve yeni sistemin paralel çalışma planı var mı?