İki yılda bir, BES otomatik katılım döngüsü yaklaştığında, birisi mutlaka bir yönetim toplantısında sesli olarak şunu söyler: "Sadece yeni katılımcı eklenmesi. Kayıt mantığı zaten çalışıyor."
İşte olay köprüsü tam da bu cümleyle başlar.
Regülatif otomatik katılım ve yeniden kayıt zorunlulukları bir pazarlama operasyonu değildir. Bunlar, senkronize, yasal olarak zaman damgalı, toplu bir poliçe başlangıç olayıdır ve katkı payı pipeline'ınızın, EGM raporlama yığınınızın ve devlet katkısı mutabakat katmanınızın üzerine inşa edildiği tüm iyimser varsayımları açığa çıkarır. Kayıt mantığının kendisi nadiren sorundur. Sorun, onun downstream'indeki her şeydir.
Batch Penceresinde Gerçekte Ne Olur
Normal bir iş gününde, bir BES operatörü onlarca işveren dosyası üzerinden belki birkaç yüz yeni katılımcı kaydı alır. Katkı payı dosyaları ay boyunca gelir. Devlet katkısı talepleri öngörülebilir bir aylık ritimde üretilir. EGM beslemeleri artımlıdır.
Bir otomatik katılım veya yeniden kayıt döngüsünde, tüm bunlar bir gecede değişir:
- Aynı yasal olarak geçerli yürürlük tarihine sahip on binlerce (bazen yüz binlerce) yeni katılımcı kaydı
- Aynı batch içinde bu poliçelere iliştirilmiş ilk katkı payları
- İnsan Kaynakları sistemleri tarafından son derece tutarsız kalitede oluşturulmuş işveren dosyaları
- Regülatif pencereler içinde gerekli EGM bildirimleri
- İlk günden doğru şekilde ayarlanması gereken devlet katkısı uygunluk bayrakları — çünkü bunları yanlış ayarlamak, aylarca çözülemeyecek mutabakat istisnalarını tetikler
Kayıt motoru bunu kaldırır. Zaten bunun için tasarlandı. Yığının geri kalanı tasarlanmadı.
Gerçekte Nerelerde Kırılıyor
1. Katkı Payı Pipeline'ı Zamansal Dağılım Varsayar
Çoğu katkı payı işleme pipeline'ı, poliçe başlangıç tarihlerinin takvim boyunca dağıldığı örtük varsayımı altında tasarlandı. Index'ler, partitioning stratejileri ve staging tablo tasarımları — hepsi sessizce buna bağımlıdır.
200.000 poliçe aynı yürürlük tarihini paylaştığında şunlar olur:
- Tarih bazlı partitioned tablolarda partition hot spot'ları
effective_datecomposite key'lerinde index şişmesi- Eskiden saniyeler içinde dönen aggregation sorgularının timeout'a düşmesi
- Başlangıç kohortuna göre gruplayan mutabakat raporlarının yüz binlerce üyeli tek satırlar üretmesi
Pipeline hata vermez. Sadece çok, çok yavaşlar ve operasyon ekibinin hızlı olmasına ihtiyaç duyduğu tam o anda yavaşlar.
2. EGM Raporlaması Delta'lar İçin İnşa Edildi
EGM (Emeklilik Gözetim Merkezi) raporlama yığınları tipik olarak artımlı değişim etrafında tasarlanmıştır. Bugün yeni poliçe, yarın durum değişikliği, ertesi gün yatırılan katkı payı. Raporlama katmanı, çıkarımlarını "son başarılı çalıştırmadan bu yana ne değişti" etrafında kurar.
Bir otomatik katılım batch'i bunu tersine çevirir. Her şey değişti. Delta, popülasyonun kendisi. Normalde birkaç megabayt üreten raporlar şimdi gigabaytlar üretir. Satır satır iterasyon yapan validation rutinleri timeout'a düşer. Ve EGM gönderim pencereleri regülatif olduğu için, sadece "yarın tekrar deneyelim" diyemezsiniz.
Ekiplerin kayıt sonrası sabah saat 3'te, EGM extract işlerinin yedi yıl önce artık şirkette çalışmayan biri tarafından yazılmış bir stored procedure'ün içinde bir yerde hardcoded satır limiti olduğunu keşfettiğini gördüm. O limit 100.000'di. Batch ise 340.000'di.
3. Devlet Katkısı Mutabakatı Steady-State Varsayar
Devlet katkısı mutabakatı, sessiz katildir. Devlet katkısı taleplerini Hazine yanıtlarıyla eşleştiren ve reddedilenleri katılımcılara geri mutabık kılan mantık, öngörülebilir red kalıplarıyla normal aylık hacim varsayılarak inşa edildi.
Otomatik katılım şunları üretir:
- Önceki çeyreğin tamamından daha büyük bir ilk ay devlet katkısı talebi
- İşveren tarafından sağlanan TCKN ve kimlik verileri normal süregelen veriden daha kirli olduğu için tırmanan red oranları
- Zaten talep edilmiş olabilecek devlet katkılarına karşı geriye dönük mutabık kılınması gereken cayma penceresi çıkışları (2 aylık cayma hakkı)
Herkesi yakalayan nokta işte bu son maddedir. Yasal pencere içinde cayan bir katılımcı, tahakkuk etmiş devlet katkısı dahil tam iadeye hak kazanır. Eğer mutabakat katmanınız devlet katkısı talebini cayma kayıt edilmeden önce işlediyse — ki işleyecek, çünkü cayma penceresi ilk katkı payı döngüsünün ötesine uzanır — artık her tek cayma için manuel bir geri sarma işiniz var.
Ölçekte, "her cayma için manuel geri sarma", altı ay boyunca özel bir ekip anlamına gelir.
Sessizce Başarısız Olan Varsayımlar
Birkaç kayıt döngüsünden gelen olay postmortemlerini incelediğimizde, örüntü tutarlıdır. Başarısızlıklar neredeyse hiçbir zaman kayıt için yazılmış kodda değildir. Yıllar önce, o zamanlar doğru olan varsayımlar altında yazılmış kodlardadır:
- Zaman damgası hassasiyet varsayımları. 50.000 poliçenin
created_atdeğerleri aynı milisaniye içinde olduğunda, sıralamaya bağımlı mantık kırılır. - Sequence ve ID üretimi. 1.000/gün'de sorun olmayan sequence'ler, 10.000/dakika'da darboğaz haline gelir.
- Downstream fan-out. CRM, doküman üretimi, hoşgeldin mektubu dağıtımı, SMS bildirimi — bunların her birinin kendi kapasite zarfı vardır ve hiçbiri toplu bir olay için boyutlandırılmamıştır.
- Mutabakat kesintileri. Günün aktivitesinin gece penceresine sığdığını varsayan gün sonu mutabakat pencereleri.
- Referans veri lookup'ları. İşveren master data'sı, sektör kodları, işyeri eşleştirmeleri — batch sırasında saniyede binlerce kez sorgulanır ve caching katmanı ya yoktu ya da bu örüntü için hiç tune edilmemişti.
Gerçekten İşe Yarayan Şeyler
Deneyime dayanarak, bir otomatik katılım döngüsünden sağ çıkan operasyonel örüntüler şöyle görünür:
- Kayıt batch'ini birinci sınıf bir release olayı olarak ele alın, olağan iş akışı değil. Diğer değişiklikleri dondurun, köprüyü personelle donatın, cache'leri ön ısıtın, sequence aralıklarını önceden tahsis edin.
- Gerçek tarihten önce en az iki kez, production ölçeğinde sentetik veriyle batch'i shadow-run edin. UAT hacmi değil. Production hacmi. Bug'lar sadece ölçekte ortaya çıkar.
- Kayıt yazma işlemini downstream fan-out'tan ayırın. Katılımcı kayıtlarını önce doğru yürürlük tarihleriyle commit edin. EGM bildirimini, doküman üretimini ve hoşgeldin iletişimini backpressure'lı async kuyruklardan akıtın. Regülatif saatler kaydı önemser; SMS bir saat bekleyebilir.
- Devlet katkısı mutabakat etkisini önceden hesaplayın. Batch çalışmadan önce cayma geri sarma senaryosunu modelleyin. En kötü durumunuzu bilin.
- Batch'i sadece satır sayısıyla değil, kohort düzeyinde metriklerle instrumente edin. "350.000 satır işlendi" size hiçbir şey söylemez. "Kohort X: 12.000 poliçe, %98,2'si geçerli TCKN'li, 87'si manuel inceleme için işaretli" size sonraki adımınızı söyler.
Asıl Ders
Otomatik katılım, kayıt mantığı karmaşık olduğu için zor değildir. BES'teki, tüm downstream sistemleri aynı anda pik yükte, katı bir regülatif tarih ve yasal bağlayıcı yürürlük tarihleriyle çalıştıran tek operasyon olduğu için zordur.
Şimdiye kadar yaklaşık, sessizce yeterince test edilmemiş veya "normal günlük hacim" etrafında inşa edilmiş her şey aynı batch penceresinde yüzeye çıkar. Ve çoğu production olayının aksine, geri alamazsınız. Yürürlük tarihleri, batch commit ettiği anda yasal olarak tesis edilir.
Otomatik katılıma bir pazarlama kampanyası gibi davranan ekipler, sonraki çeyreği temizlik yaparak geçirir. Ona koordineli bir toplu başlangıç release'i olarak, bir core sistem migrasyonuyla aynı titizlikte davranan ekipler ise o çeyreği başka bir şey üzerinde çalışarak geçirir.