Regülasyon Raporlamasında Dondurma Sorunu: BES Pipeline'ları Gönderim Pencerelerinde Neden Normal Operasyonları İşleyemez

Birlikte çalıştığım her BES (Bireysel Emeklilik Sistemi) ekibi, genellikle üçüncü veya dördüncü EGM gönderim döngüsü civarında aynı duvara toslar. Uyum tarafından biri "sadece Cuma pozisyonuna dair bir rapora ihtiyacımız var" der. Mühendislik tarafından biri bir sorgu yazar. İki ay boyunca çalışır. Sonra bir katkı geç kaydedilir, bir fon yeniden değerlemesi ekstraksiyon ortasında düşer ya da bir katılımcı transferi aynı pipeline'daki iki join arasında yürütülür — ve birden bire saklamacıyla mutabık kılınan sayılar, regülatöre sunulan sayılardan 180.000 hesap üzerinde 47 kuruş farklı çıkar.

O 47 kuruş bir yuvarlama hatası değildir. Bir tutarlılık sınırı ihlalidir. Ve emeklilik sistemlerinde regülasyon raporlamasının asıl mühendislik problemi budur.

Gönderim Pencerelerinin Bir Raporlama Görevi Olduğu Yanılsaması

Standart çerçeveleme şöyledir: regülatör T anındaki bir snapshot ister. T+1 sabahı ekstraksiyon yaparsın. T+2'de gönderirsin. Bitti.

Bu çerçeveleme kağıt üzerinde işler çünkü altta yatan sistemin hareketsiz durduğunu varsayar. Üretimde aşağıdakilerin hiçbiri gönderim pencereniz boyunca durmaz:

• İşverenlerden katkı dosyaları gelmeye ve geriye dönük kayıtlar oluşturmaya devam eder
• Fon NAV'ları, portföy yönetim şirketi tarafından değerleme tarihinden iki üç gün sonra düzeltilir
• Katılımcı yaşam döngüsü olayları (giriş, çıkış, fon değişikliği, hak ediş) yazılmaya devam eder
• Önceki haftanın takas hatalarından kaynaklanan ters işlemler, T tarihli pozisyonlara karşı kaydedilir
• Aktarım akışları, ekstraksiyonunuzdan önceki tarihli, yasal olarak bağlayıcı geçerlilik tarihleriyle yürütülür

Pipeline statik bir sistem üzerinde raporlama yapmıyor. Siz onu tanımlamaya çalışırken geçmişi aktif olarak yeniden yazan bir sistem üzerinde raporlama yapıyor.

Dondurma Aslında Neye Benziyor

Gördüğüm Türk emeklilik operasyonlarının çoğunda, "dondurma" teknik bir mekanizma değildir. "Onur EGM ekstraksiyonunu bitirene kadar kimse hiçbir şey çalıştırmasın" diyen bir WhatsApp mesajıdır. Bu şaka değil — gerçek kontrol budur.

Var olma nedeni, ekstraksiyon mantığının neredeyse her zaman birden fazla sorguyu kapsamasıdır: biri katılımcı master için, biri fon pozisyonları için, biri katkı defteri için, biri devlet katkısı eşleştirmesi için, biri yaşam döngüsü olayları için. Bu sorgular bir transaction paylaşmaz. Sorgu 2 ile sorgu 3 arasında bir fon değişikliği commit edilirse, katılımcı pozisyon tablosunda A fonunda, olay tablosunda ise B fonunda görünür. Her iki sayı da makul göründüğü için mutabakat sessizce başarısız olur.

Operasyonel dondurma, bir snapshot izolasyon stratejisinin yokluğuna karşı insan eliyle konulmuş bir yamadır.

Neden Sadece Bir Read Replica Kullanamazsınız

Yaygın öneri — ekstraksiyonu bir read replica'ya veya bir veri ambarına yönlendirmek — yanlış problemi çözer. Size stabil bir okuma yüzeyi verir ama yasal olarak tutarlı bir yüzey değil. Şunu düşünün:

• Replica 15 dakika geride. 23:58'de geldiği için yasal olarak T'ye sayılan bir katkı, işiniz 00:15'te başladığında replica'da olmayabilir.
• Saklamacıdan geç gelen düzeltmeler, OLTP sistemine geriye dönük valid_from zaman damgalarıyla iletilir. Replica'nız bunları yeni satırlar olarak görür; regülatör mantığınız ise bunları önceki bir duruma dair değişiklikler olarak ele almak zorundadır.
• Ambar ETL'inin kendisi, kendi tutarlılık penceresi olan bir pipeline'dır. Artık bir yerine iki sınır savunuyorsunuz.

Bir replica size okuma stabilitesi verir. Regülasyon gönderimi ise zamansal doğruluk gerektirir — çok farklı bir özellik.

Gerçek Tasarım: Açık Kesim Noktalarıyla Bitemporal Snapshot'lar

Denetimden temiz çıktığını gördüğüm tek mimari, her regülasyonla ilgili tabloyu bitemporal olarak ele alan mimaridir: hem iş etki tarihini hem de sistem transaction tarihini saklar. Gönderim pipeline'ı, naif versiyonun yapmadığı iki şey yapar:

• Ekstraksiyonun başında bir sistem zamanı kesim noktası belirler ve bunu çalıştırmadaki her sorguda sabit olarak kullanır
• İş tarihi filtrelerini ayrı olarak uygular; böylece system_time = T+3'te, effective_date = T-2 ile kaydedilen bir düzeltme, ETL'in ne zaman gördüğüne göre değil, regülatörün kuralına göre dahil edilir veya edilmez

Somut olarak, her ekstraksiyon sorgusuna WHERE system_recorded_at <= :cutoff_ts yüklemi eklenir ve :cutoff_ts işin başında bir kez yakalanıp mutabakat dahil her aşağı akış adımına aktarılır. Bu, dondurmanın yerine geçer. Üretim yazmaya devam eder. Raporunuz kesim noktasından sonra yazılan hiçbir şeyi görmez.

Kimsenin Bütçelemediği Değişiklik Sorunu

Bitemporal snapshot'larla bile, gönderimden sonra bir düzeltme geldiğinde ne olacağına dair regülatöre bir cevap borçlusunuz. Bir portföy yönetim şirketi, siz gönderdikten üç gün sonra raporlama tarihi için yeni bir NAV yayımlarsa, sunduğunuz rapor tanımı gereği artık yanlıştır.

Pratikteki operasyonel cevap:

• Her gönderim bir versiyon numarası ve karşısında oluşturulduğu kesim zaman damgasını taşır
• Değişiklikler taze ekstraksiyonlar olarak değil, son sunulan snapshot'a karşı delta olarak hesaplanır
• Denetim izi, gönderim anında tam olarak neyin bilindiğini yeniden kurabilmelidir — sistem zamanı kesim noktasının sadece bir ETL numarası değil, yasal delil olmasının nedeni budur

Bunu atlayan ekipler ya hataları düzeltmeyi reddederler (regülatör eninde sonunda fark eder) ya da geçmişi üzerine yazarlar (regülatör daha hızlı fark eder).

Aslında Ne İnşa Etmeli

Şu anda WhatsApp dondurmasına dayanan bir BES pipeline'ına bakıyorsanız, göç yolu göz alıcı değil ama sonlu:

• Regülasyon ekstraksiyonunun dokunduğu her tabloya system_recorded_at ve effective_from / effective_to kolonları ekleyin. Mümkün olduğunda transaction loglarından geriye doldurun.
• Ekstraksiyonu, bir kesim zaman damgası yakalayan ve tüm aşağı akış mutabakatları ve doğrulamaları dahil her sorguya aktaran tek bir iş olarak yeniden yazın.
• Sunulan snapshot'ı değişmez bir artefakt olarak saklayın — object storage üzerinde parquet uygun — gönderim versiyonu ve kesim noktasıyla anahtarlanmış.
• Değişiklik yolunu, yeniden ekstraksiyon olarak değil, saklanan snapshot'a karşı bir diff olarak inşa edin.
• Operasyonel dondurmayı en son kaldırın, yalnızca üç dört döngü snapshot mantığının kuruşuna kadar mutabık kaldığını gösterdikten sonra.

Bunu yapmanın nedeni zarafet değildir. Nedeni, dondurmanın eninde sonunda kırılmasıdır — biri bir iş çalıştırır, bir işveren dosyası geç gelir, bir fon yeniden değerlemesi ertelenmez — ve mutabakat farkı bir regülasyon bulgusuna dönüşür. Mühendislik problemi hiçbir zaman rapor değildi. Sınırın var olduğunu bilmeyen bir üretim sistemine karşı bir tutarlılık sınırını savunmaktı.