Düzenlenmiş sektörlerde çalışan her veri mühendisi, uyumluluk için sistem inşa etmeyi öğrenir. Çoğunun birkaç yıllık rapor gönderdikten sonra fark ettiği şey ise uyumluluğun naif mimarileri kıran bir zaman boyutuna sahip olduğudur.
EGM'ye bir GEV raporu, sigorta birliğine bir HAYMER kaydı veya Hazine'ye bir devlet katkısı hesaplaması gönderdiğinizde, kalıcı tek bir beyanda bulunmuyorsunuz. Düzenleyicinin daha sonra — bazen yıllar sonra — gönderim anında var olmayan kuralları kullanarak yeniden yorumlayabileceği bir beyanda bulunuyorsunuz. Ve bunu yaptıklarında, sizden orijinal sürümü değil, düzeltilmiş sürümü üretmeniz bekleniyor.
Bu, geriye dönük mevzuat değişikliği sorunudur ve Türk finansında gördüğüm hemen hemen her pipeline, mimari olarak buna hazırlıksızdır.
İki Farklı Uyumluluk Sorunu
Bir düzenleyicinin tarihsel verileriniz hakkında sorabileceği iki ayrı soru vardır:
- Bu gönderim, gönderim anında yürürlükte olan kurallara göre doğru muydu?
- Bu gönderim, mevcut tanımlanmış kurallarla eşleşiyor mu?
Ekiplerin çoğu, ilk soruya iyi cevap veren sistemler kurar. Neyin, ne zaman, hangi şema ile ve hangi doğrulama mantığına karşı gönderildiğini loglarlar. Gönderim yaptıkları gün uyumlu olduklarını kanıtlayabilirler.
Denetimlerde, mutabakat taleplerinde ve düzeltme döngülerinde aslında karşımıza çıkan ikinci sorudur. Ve bu, temelden farklı bir mühendislik problemidir; çünkü tarihsel girdileri, o girdiler oluşturulduğunda mevcut olmayan kural setlerine karşı yeniden inşa etmeyi gerektirir.
Devlet Katkısından Somut Bir Örnek
Devlet katkısı pipeline'ı, 2013'ten bu yana birkaç yorumlama döngüsünden geçti. Basit bir örnek: eşleştirme amaçları için "uygun katkı" olarak sayılan şeyin tanımı defalarca netleştirildi, daraltıldı ve yeniden genişletildi. Kısmi ay girişleri, işveren destekli dönüşümler ve iade tersine çevirmeleri etrafındaki uç durumların hepsi geriye dönük olarak yeniden tanımlandı.
Yeni bir yorum geldiğinde, genellikle özetle şunu söyleyen bir genelge alırsınız: son N ayı yeni kurallara göre yeniden hesaplayın, tutarsızlıkları tespit edin, düzeltmeleri gönderin ve katılımcılara halihazırda yansıtılmış eşleştirme tutarlarını mutabık kılın.
Pipeline mimariniz şuna benziyorsa:
- Kaynak sistemler → dönüşüm → gönderim dosyası → arşiv
o zaman başınız belada demektir. Çünkü arşiv, çıktıyı içerir; girdileri orijinal formunda içermez ve kesinlikle farklı bir kural setine karşı tekrar oynatılabilecek bir formda içermez. Sonuç olarak, durumu çoktan ilerlemiş üretim OLTP sistemlerinden yeniden inşa etmeye çalışırsınız — ekiplerin tam da o noktada birinin üç ay önce bir katılımcı kaydını değiştirdiğini ve tekrar oynatma için geri almaya yetecek ayrıntıda bir denetim izi olmadığını keşfettiği yer burasıdır.
HAYMER ve GEV'in Bana Öğrettikleri
HAYMER ve GEV benzer dinamiklere sahiptir. Teknik şema görece sabit kalır, ancak alanların semantik yorumu kayar. 2019'da bir anlama gelen bir poliçe durum kodu, 2022'de netleştirilmiş bir tanım kazanır ve artık 2019–2021 gönderimleriniz — o zaman doğru olmalarına rağmen — 2022 kurallarına göre teknik olarak yanlıştır.
Düzenleyici düzeltilmiş bir yeniden gönderim istediğinde, çoğu pipeline'ın korumadığı üç şeye ihtiyacınız vardır:
- Sadece dönüştürülmüş çıktı değil, gönderim anında var olduğu haliyle ham girdi durumu
- Orijinal gönderimi üreten dönüşüm mantığı sürümü
- Yeni dönüşüm mantığını, mevcut üretim durumuyla kirletmeden eski ham girdi durumuna uygulamanın bir yolu
Bunlardan herhangi birinin eksik olması, bir haftalık bir düzeltme projesini altı aylık bir arkeoloji kazısına dönüştürür.
Mimari Kayma
Yeterince fazla bu döngüden geçtikten sonra çıkarılan ders şudur: gönderim pipeline'ları bitemporal sistemler olarak modellenmelidir. Birbirinden bağımsız iki zaman çizelgesini takip etmeniz gerekir:
- İş zamanı (business time): olayın gerçekten ne zaman gerçekleştiği (katkının ne zaman yapıldığı, poliçenin ne zaman düzenlendiği)
- Sistem zamanı (system time): sisteminizin bunu ne zaman öğrendiği ve hangi kural sürümünün uygulandığı
Somut olarak bu şu anlama gelir:
- Gönderim anında değişmez (immutable) ham girdi anlık görüntüleri. Dönüştürülmüş çıktı değil — girdiler. Sonraki güncellemelerin bozmaması için üretim OLTP'sinden ayrı olarak saklanır.
- Sürümlenmiş dönüşüm mantığı, her gönderime açık sürüm etiketleri eklenmiş kod olarak dağıtılır. "Bu dosya v4.7 kural seti tarafından üretildi" sorgulanabilir olmalıdır.
- Tekrar oynatma (replay) yeteneği, birinci sınıf bir özellik olarak. Dönüşüm mantığının herhangi bir sürümünü herhangi bir tarihsel girdi anlık görüntüsüne yönlendirip deterministik bir çıktı üretebilmelisiniz. Bu pazarlık konusu değildir ve neredeyse hiç kimse bunu birinci günden inşa etmez.
- Diff araçları, orijinal gönderimi yeni kurallar altındaki bir tekrar oynatmayla karşılaştırır; böylece toptan yeniden gönderimler yerine savunulabilir düzeltme raporları üretebilirsiniz.
Bunların hiçbiri egzotik teknoloji değildir. Düzenleyici kural setinin sürümlenmiş bir reducer olarak ele alındığı event sourcing ile aynı desendir. Zor olan kısım teknik değildir; ek depolama ve karmaşıklığın değerli olduğuna iş tarafını, ilk geriye dönük değişiklik konuşmayı zorunlu kılmadan önce ikna etmektir.
Bunu Atlarsanız Maliyeti Ne Olur
Yalnızca gönderim anı uyumluluğu için sistem kuran ekipler, bunun bedelini öngörülebilir üç şekilde öder:
- Düzeltme döngüleri, operasyonel görevler değil, mühendislik projelerine dönüşür. Her geriye dönük kural değişikliği, üretim veri çıkartmalarını, manuel mutabakatı ve yeniden inşa sırasında ek hata riskini içeren çok haftalık bir çabayı tetikler.
- Denetim savunulabilirliği zamanla aşınır. Ne gönderdiğinizi açıklayabilirsiniz, ancak belirli bir girdi durumuna uygulanan belirli bir kural setinin neden doğru çıktısı olduğunu kolayca gösteremezsiniz. "Bize güvenin, o zamanki mantık buydu" kabul edilebilir bir cevap değildir.
- Düzenleyici ile mutabakat çekişmeli hale gelir. Onların yeniden hesaplaması sizinkiyle uyuşmadığında ve kendi geçmişinizi tekrar oynatamadığınızda, tartışmayı varsayılan olarak kaybedersiniz.
Pratik Çıkarım
Türk emeklilik, sigorta veya benzer şekilde düzenlenmiş herhangi bir alanda bir mevzuat pipeline'ı inşa ediyor veya sürdürüyorsanız, mevcut mimarinize tek bir soru sorun: bugün, on sekiz ay önce yapılmış bir gönderimin girdilerini alıp, gelecek yıl yazacağınız bir kural seti üzerinden tekrar oynatabilir ve deterministik, savunulabilir bir çıktı üretebilir misiniz?
Cevap hayırsa, uyumluluk için inşa etmiyorsunuz demektir. Gönderim için inşa ediyorsunuz. Bu ikisi aynı şey değildir ve farkın ne zaman önemli olduğuna karar veren düzenleyicidir.