Birlikte çalıştığım her BES operasyon ekibinin aynı hikâyesi vardır. Bir katılımcı vefat eder. Dul eş elinde bir mahkeme kararı, veraset ilamı ve eşinin on sekiz yılda biriktirdiği emeklilik tasarrufunun mücadele edilmeden ödeneceği beklentisiyle gelir. Sonra süreç tıkanır ve nedeni neredeyse her zaman aynıdır: birileri, bir yerlerde, bir zaman, hesabı yasal bir temsilci — bir vekaletname, bir vasi, mahkeme atamalı bir kayyum — tarafından yönetilen olarak işaretlemiştir ve bu bayrak hâlâ kaydın üzerinde sessizce durmaktadır; arkasında bir geçmiş, önünde bir son kullanma tarihi olmadan.
Bu bir form tasarımı sorunu değildir. Bu, sektörün on yıldır kaçındığı bir veri modelleme sorunudur; çünkü sorunu çözmek, hukuki yetkinin bir katılımcının niteliği olmadığını kabul etmek anlamına gelir. Hukuki yetki, bir ömrü olan bir olaydır.
Bugün Hesapta Aslında Ne Duruyor
Üretimdeki neredeyse herhangi bir BES katılımcı tablosunu açın; hesaba iliştirilmiş şu türden alanlar göreceksiniz:
legal_rep_flag(boolean)legal_rep_tckn(temsilcinin kimlik numarası)legal_rep_type(vekaletname, vasi, kayyum)legal_rep_start_date(bazen)legal_rep_end_date(nadiren doldurulur, çoğu zaman NULL — geleneksel olarak "hâlâ geçerli" anlamına gelir)
Yeni bir yetki belgesi geldiğinde operasyon kullanıcısı kaydı açar ve alanların üzerine yazar. Eski temsilci kaybolur. Belge referansı, varsa, değiştirilir. Yetkinin verilme nedeni — demans teşhisi, uzun süreli yurt dışı seyahati, küçük lehtar için mahkeme atamalı vesayet — şemada hiçbir yerde yoktur. Önceki yetkiyi sona erdiren olay da kaydedilmemiştir. Tek bir satır vardır. Bu satır, son veri girişi yapan memurun yazdığı ne ise onu yansıtır.
Bu arada, aşağı akıştaki sistemler bu satırı gerçek olarak okur. Ödeme motoru legal_rep_flag'i kontrol eder. Başka bir emeklilik şirketine aktarım yapan transfer-out API'si legal_rep_flag'i kontrol eder. Vefat talebi iş akışı legal_rep_flag'i kontrol eder. Hiçbiri bunun ne zaman, hangi belgeyle, hangi hukuki dayanakla belirlendiğini ya da altta yatan mahkeme kararının o zamandan bu yana iptal edilip edilmediğini sormaz.
Bu Uygulamada Nerede Çöker
Dört senaryo tekrar eder ve her birinin haftalarca süren manuel mutabakata mal olduğunu gördüm.
Senaryo bir: emeklilik şirketine kimsenin bildirmediği süresi dolmuş vekaletname. Türkiye'de noter tasdikli bir vekaletname tipik olarak ya belirli bir süre taşır ya da belirli bir amaca bağlıdır. Süresi dolduğunda noter emeklilik sağlayıcısını aramaz. Bayrak yerinde kalır. İki yıl sonra katılımcı bir rakibe aktarılır, temsilci imzalar ve aktarım sonuçlanır. Katılımcı bunu fark ettiğinde, geri alma işlemi SGK raporlamasını, ara dönem kısmi ödemeler üzerindeki vergi stopajını ve devlet katkısı hesaplamasını etkiler. Hepsi geri sarılmak zorundadır çünkü kimse yetki kaydını versiyonlamamıştır.
Senaryo iki: vesayeti altındaki kişi on sekiz yaşına giren vasi. Küçük bir lehtarın hesabı, yasal vesayet altında bir ebeveyn tarafından yönetilir. On sekizinci doğum gününde bu yetki yasa gereği sona erer. Hiçbir belge sunulmaz. Hiçbir sistem olayı tetiklenmez. Bayrak yerinde kalır. Artık yetişkin olan katılımcı, hesap üzerinde ilk bağımsız kararını almaya çalıştığında, iş akışı onay SMS'ini ebeveynin telefon numarasına yönlendirir; çünkü temsilci kaydı hâlâ öyle diyor.
Senaryo üç: vefat edenin başka birinin temsilcisi de olduğu vefat talebi. Vefat eden katılımcı, engelli kardeşinin BES hesabı için mahkeme atamalı vasidir. Onun ölümü bu yetkiyi sona erdirir. Ancak kardeşin hesabı aylarca onu aktif temsilci olarak göstermeye devam eder; çünkü bir hesaptaki vefat olayı ile diğer hesaptaki yetki kaydı arasında hiçbir çapraz referans yoktur.
Senaryo dört: önbelleklenmiş bir görünümde sonsuza dek yaşayan iptal edilmiş vekaletname. Operasyon bayrağı günceller. Ana sistem bunu yansıtır. Her gece yenilenen raporlama ambarı bunu ertesi gün alır. Haftalık yenilenen bir materialized view'dan okuyan ödeme ön yüzü almaz. İptal edilmiş bir temsilci tarafından imzalanan bir ödeme talebi Çarşamba günü sonuçlanır; çünkü yetki kontrolü bayat veriye çarpmıştır.
Neden "Daha İyi Formlar" Bunu Çözmez
Son beş yılda gördüğüm her satıcı sunumu aynı çözümü önerir: daha zengin bir kayıt formu, bir belge yönetim modülü, kullanıcıyı bir tarama eklemeye zorlayan bir iş akışı. Hiçbiri altta yatan modeli ele almaz. Yetki durumu hâlâ tek, üzerine yazılabilir bir alan olarak saklanan bir kayda yüz PDF ekleyebilirsiniz. Bir sonraki olay geldiğinde ve memur satırı düzenlediğinde, geçmiş kaybolur ve tüm aşağı akış tüketicileri yeni durumu sanki her zaman doğruymuş gibi okur.
Sorun kayıt alma değildir. Sorun, hukuki yetkinin aslında bir olaylar dizisi iken bir özellik olarak modellenmesidir.
Olay Kaynaklı (Event-Sourced) Alternatif
Yetkiyi kendi tablosu olarak, yalnızca ekleme yapılabilen (append-only) biçimde ve kendi zamansal ekseniyle ele alın. Her kayıt bir hukuki olayı temsil eder:
authority_id(değişmez)participant_idrepresentative_identityauthority_type(vekaletname, yasal vesayet, mahkeme atamalı kayyum, veraset geçişi)legal_basis_document_ref(noter yevmiye numarası, mahkeme karar numarası, ölüm belgesi seri numarası)granted_at(hukuki belgenin yürürlüğe girdiği zaman — memurun girdiği zaman değil)expires_at(açık; yalnızca yetki türü yasal olarak süresiz olduğunda NULL)terminated_at(üzerine yazılarak değil, sonraki bir olayla doldurulur)termination_event_id(bu yetkiyi sona erdiren olaya yabancı anahtar)recorded_at(sistem zamanı, hukuki zamandan ayrı)
Herhangi bir andaki yetki durumu bir arama değil, bir sorgu haline gelir. "14 Mart 2022'de bu katılımcı için kim imza atabilirdi?" cevaplanabilir. "Bu aktarım, gerçekleştirildiği anda geçerli bir belge altında yetkilendirilmiş miydi?" cevaplanabilir. "Temsilcisi o zamandan beri vefat etmiş olan tüm hesapları göster" cevaplanabilir ve bu, ailenin yaşamak zorunda kalmadan önce üçüncü senaryoyu yakalayan sorgudur.
Kritik olarak, şema hukuki zamanı sistem zamanından ayırır. 3 Ocak tarihli, operasyona 20 Şubat'ta ulaşan bir mahkeme kararı granted_at = 3 Ocak ve recorded_at = 20 Şubat olarak kaydedilmelidir. Denetçiler her ikisine de ihtiyaç duyar. Bitemporal modelleme burada akademik bir konu değildir — bir ödeme kararını mahkemede savunmak ile kaybetmek arasındaki farktır.
Uygulama Maliyeti
Dürüst olmak gerekirse, bu arızaların halihazırda ürettiği manuel mutabakatın yıllık maliyetinden daha az. Çoğu ekibin özümseyebileceği geçiş yolu:
- Mevcut bayrağı güncel durum önbelleği olarak dondurun, ancak onu doğruluk kaynağı olarak kabul etmeyi bırakın.
- Yanında yetki olayı tablosunu kurun; mevcut belge kanıtından geriye doğru doldurun ve geçmiş kaydın eksik olduğu yerlerde
backfilled = trueişareti bırakın. - Her aşağı akış yetki kontrolünü, açık bir "şu tarih itibarıyla" zaman damgasıyla olay tablosunu sorgulayacak şekilde yeniden yazın — bu genellikle mevcut zaman değil, yetkilendirilen işlemin zaman damgasıdır.
- Yetkiler sona erdiğinde olay yayan zamanlanmış bir iş olarak süre dolumu izlemesi ekleyin; böylece aşağı akış önbellekleri sessizce sürüklenmek yerine geçersiz kılınır.
En zor kısım teknik değildir. Operasyon liderliğini, on yıldır üzerine yazdıkları yetki alanının hiçbir zaman yeterli olmadığına ve işlerin yürüyormuş gibi görünmesinin nedeninin, arızaların vefat talepleri sırasında müşteri şikâyeti olarak soğrulması olduğuna — yani şikâyetçilerin yaslı olması nedeniyle en az düzenleyici eyleme dönüşme olasılığı bulunan anlarda — ikna etmektir.
Rahatsız Edici Kısım
Katılımcılar ve aileleri bu sistemle üç anda karşılaşır: hesabı açarken, aktarırken ve kapatırken — sonuncusu genellikle birinin vefatı nedeniyle. Bu üç andan ikisi tam olarak yetki modelinin en görünür şekilde başarısız olduğu anlardır. Sektör bunu tolere etmiştir; çünkü arızalar dağınık, sessizdir ve düzenleyiciye resmi bir şikâyet sunacak konumda olmayan insanların üzerine düşer.
Bu teknik bir mazeret değildir. Bu, düzeltmenin neden gecikmiş olduğunun nedenidir.