Katkı Geçmişini Yeniden İnşa Etme Problemi: Bir Katılımcı 10 Yıllık Kayıtlara İtiraz Ettiğinde

Bir katılımcı, elinde bordro klasörüyle çağrı merkezine geliyor ve emeklilik ekstresinin 2014 ile 2019 arasında biriken katkılarını yaklaşık 14.000 TL eksik gösterdiğini söylüyor. Temsilci durumu üst yönetime taşıyor. Operasyon ekibi taşıyor. Sonunda mesele veri ekibine düşüyor; çünkü artık doğruluk kaynağı (source of truth) net değil — ve bu, hikâyenin kibar versiyonu.

Müşteri şikâyeti gibi görünen şey, aslında bir bitemporal arkeoloji problemidir. Sizden, sistemin bu katılımcı hakkında belirli bir tarihsel anda neye inandığını yeniden inşa etmeniz isteniyor; bunu yaparken o anda gerçekte neyin doğru olduğunu da bilmeniz gerekiyor. Bunlar iki farklı zaman çizgisidir ve pipeline'ınız bunları birbirine karıştırırsa, cevabınızı bir düzenleyici ya da mahkeme karşısında savunamazsınız.

Bu, yazacağınız en zor sorgu neden?

Çoğu analitik sorgu şu soruya cevap verir: şu an durum nedir? Birkaçı şuna cevap verir: X tarihinde durum neydi? Neredeyse hiçbiri burada önemli olan soruya cevap vermez:

31 Mart 2017 tarihinde, yalnızca o tarihte elimizdeki bilgilerle, sistemimiz katkı bakiyesi olarak ne raporladı ve bunu şimdi 31 Mart 2017 için doğru olduğuna inandığımız değerle nasıl karşılaştırırız?

Naif uygulamaları öldüren işte bu ikinci cümledir. 2014'ten bugüne kadar, bu katılımcının kayıtlarına neredeyse kesin olarak şunlar olmuştur:

• İşveren bir katkı dosyasını geç gönderdi ve dosya geriye dönük tarihlendi
• 2018'deki bir bordro düzeltmesi, 2016'daki bir katkıyı geriye dönük olarak değiştirdi
• Katılımcı iki kez fon değiştirdi; NAV düzeltmesi nedeniyle birim fiyatlar bir kez yeniden hesaplandı
• Çekirdek sisteminiz 2017'de migrate edildi ve eski katkı tablosu bilgi kaybına yol açan bir dönüşümle arşivlendi
• Düzenleyici raporlama kuralları 2019'da değişti ve "hak edilmiş katkı" hesaplaması yeniden tanımlandı
• 2020'deki bir mutabakat işi, sahipsiz olarak işaretlenmiş yaklaşık 3.000 kaydı sessizce düzeltti

Bunların her biri meşru bir iş olayıdır. Birlikte ele alındığında, katkı geçmişinin bir log olmadığını gösterirler — bu bir palimpsesttir.

Tek değil, iki zaman çizgisi

Minimum uygulanabilir model bitemporaldir:

• Valid time: Katkının gerçek dünyada katılımcının hesabına fiilen uygulandığı zaman
• Transaction time: Sisteminizin bundan haberdar olduğu zaman

Mart 2016 bordrosu için bir katkı (valid time), 5 Nisan 2016'da kaydedilmiş (transaction time), 12 Kasım 2018'de düzeltilmiş (yeni transaction time, aynı valid time) ve ardından 2020 mutabakatı sırasında yeniden düzeltilmiş olabilir (üçüncü transaction time, hâlâ aynı valid time).

"Katılımcıya 2017 yıllık ekstresinde ne söyledik?" sorusunu yanıtlamak için transaction time ≤ 2017-01-31 gerekir. "Onlara ne söylememiz gerekirdi?" sorusunu yanıtlamak için ise valid time ≤ 2016-12-31 olan en güncel transaction-time görünümüne ihtiyacınız vardır. Uyuşmazlık neredeyse her zaman bu iki cevap arasındaki farkla ilgilidir.

Katkı tablonuzda yalnızca tek bir updated_at sütunu varsa ve yerinde üzerine yazıyorsanız, oyunu çoktan kaybettiniz. Yeniden inşa; veritabanı yedeklerine, CDC loglarına ya da o dönemde gönderdiğiniz düzenleyici raporlara bağlı olacaktır — ve doğruluk kaynağı olarak kendi veritabanınızı değil, o raporları okuyor olacaksınız.

Savunulabilir bir yeniden inşa aslında neyi gerektirir?

Pratikte, bunu bir sigorta veya emeklilik bağlamında bir araya getirmek zorunda kaldığımda, girdiler asla tek bir tablodan ibaret olmamıştır. İhtiyacınız olanlar:

1. Tam geçmişe sahip katkı defteri (ledger) — yalnızca ekleme yapılabilen (append-only), hem valid_from/valid_to hem de recorded_from/recorded_to alanlarına sahip. Buna sahip değilseniz, yedek planınız bir sonraki maddedir.
2. Arşivlenmiş düzenleyici gönderimler — düzenleyiciye aylık olarak gönderilen dosyalar zaman damgalıdır, değiştirilemez ve hukuken otoritedir. Çoğu zaman elinizdeki tek temiz point-in-time anlık görüntü bunlardır.
3. PDF olarak yıllık katılımcı ekstreleri — katılımcının fiilen aldığı şey. Mahkemeye getirecekleri budur. Yeniden inşanız, bu belgedeki her rakamı açıklayabilmelidir.
4. Fon değişikliği ve birim fiyat geçmişi — ayrı bir bitemporal yapı olarak, çünkü NAV yeniden hesaplamaları kendi başına bir geriye dönük değişiklik kategorisidir.
5. Schema migration eşleme belgeleri — 2017 migration'ı üç katkı türünü ikiye indirgediyse, geriye doğru yürümek için eşlemeye ihtiyacınız vardır.
6. Hesaplama motoru sürümü — 2016'daki hak edilmiş bakiye formülü, 2024'teki formül değildir. Tarihsel formülü tarihsel veri üzerinde çalıştırmanız gerekir.

Son nokta, çoğu ekibin gözden kaçırdığı noktadır. Girdileri mükemmel şekilde yeniden inşa etseniz bile, bugünün hesaplama mantığını 2016 verisine uygulamak size kendi içinde tutarlı ama hukuken yanlış bir rakam verir. Sadece sürümlenmiş veriye değil, sürümlenmiş iş mantığına ihtiyacınız var.

Sorgu, kabaca

Bir katılımcı, bir tarih için gerçek bir yeniden inşa sorgusunun şekli şuna benzer:

• valid_time <= target_date VE transaction_time <= as_of_date olan tüm katkı satırlarını çekin
• Her (katılımcı, valid_period) için, hâlâ ≤ as_of_date olan en yüksek transaction_time'a sahip satırı alın
• Aynı bitemporal mantığı kullanarak fon dağılım tablosuyla join yapın
• NAV yeniden hesaplama bayrakları dahil olmak üzere, aynı mantıkla birim fiyat tablosuyla join yapın
• as_of_date'te aktif olan hesaplama motoru sürümünü uygulayın
• Çıktıyı, en yakın ay sonu için arşivlenmiş düzenleyici gönderimle mutabık kılın
• Mutabakat farkı toleransı aşan herhangi bir satırı işaretleyin

O son adım pazarlık konusu değildir. Yeniden inşanız, o dönemde gönderdiğiniz düzenleyici dosyayla örtüşmüyorsa, yeniden inşanız yanlıştır — ya da dosya yanlıştır, ki bu çok daha büyük bir problemdir.

Operasyonel sonuçlar

Bunu ciddiye alırsanız, birkaç şey doğal olarak takip eder:

• Append-only katkı defterleri opsiyonel değildir. Bir kaydı "düzeltmek" için yerinde güncelleme yapmak, kanıtı yok etmektir. Düzeltmeler yeni satırlardır.
• Schema migration'lar, migration öncesi tabloyu korumalıdır, sadece veriyi değil. Eşleme mantığı, denetim izinin bir parçasıdır.
• İş kuralı değişiklikleri sürüm etiketlerine ve yürürlük tarihlerine ihtiyaç duyar; bunlar üzerinde çalıştıkları veriyle birlikte saklanmalıdır.
• Düzenleyici gönderimler sizin gerçek yedeğinizdir. Onları arşivlenip unutulacak çıktı eserleri olarak değil, birinci sınıf veri varlıkları olarak ele alın.
• Uyuşmazlıklar, her seferinde özel bir soruşturma değil, standart bir yeniden inşa iş akışını tetiklemelidir. İlk uyuşmazlık arkeolojidir; yüzüncüsü parametrik bir sorgu olmalıdır.

Gördüğüm Türk emeklilik ve sigorta operasyonlarının çoğu, bu listede 1. ile 3. adım arasında bir yerdedir. Oraya ulaşmanın maliyeti gerçektir, ancak kendi rakamlarınızı açıklayamadığınız ve kaybettiğiniz tek bir mahkeme davasının maliyetinden çok daha küçüktür.

Rahatsız edici kısım

Yeniden inşayı sonunda ortaya çıkardığınızda, katılımcının haklı olma ihtimali yabana atılır cinsten değildir. 14.000 TL'lik fark gerçektir ve izi, mevcut bakiyeye uygulanmış ancak tarihsel ekstre mantığına hiç yansıtılmamış 2018 bordro düzeltmesine kadar gider. Bu, uyuşmazlık sırasında keşfettiğiniz bir veri problemi değildir — bu, altı yıldır bilinmeyen sayıda başka katılımcıyı sessizce etkileyen bir veri problemidir.

Katkı geçmişi uyuşmazlıklarının binadaki en pahalı talepler olmasının nedeni budur. Size sadece bir katılımcıyla yapılan uzlaşmanın maliyetini yüklemezler. Aynı kusurun 40.000 hesaba dokunduğunu fark ettiğinizde ortaya çıkan mutabakat projesinin maliyetini de yüklerler.

Sorgu zordur. Temizlik daha da zordur. Bitemporal altyapı inşa etmekten daha pahalı olan tek şey, onu inşa etmemek ve on yıl sonra müşterilerinize ne söylediğinizi kanıtlayamadığınızı keşfetmektir.