Doğrulama çerçevesi, olay kaynaklama'nın değişmez ve yalnızca ekleme doğası ile en az bir kez teslimin mekanik sınırlamaları ve eski sistem gecikmeleri arasında uyum sağlamak üzerinde yoğunlaşmaktadır. Kopya bildirimin oluşturulmasını önlemek için, uygulama katmanında idempotans garantileri sağlamanız gerekmektedir, böylece kopya Kafka mesajları yan etkisiz aynı olay depolama girdilerini üretir. Mimari, uyum raporlamasını yüksek hızlı ticaret yolundan ayırarak hız için optimize edilmiş CQRS okuma modelleri kullanmakta ve kritik yolda engel olmadan eski Oracle denetim deposunu beslemek için asenkron Değişiklik Veri Yakalama (CDC) kullanmaktadır.
Monolitik Java EE platformundan Spring Boot mikro servislerine geçiş yapan bir niceliksel ticaret şirketi tam olarak bu sorunla karşılaştı. Alan, her sipariş değişikliğinin — fiyat güncellemeleri, iptaller, işlemler — değişmez olaylar olarak izlenmesini gerektiriyordu ki bu da SEC Kuralı 17a-4(b) denetim izi gereksinimlerini yerine getirsin. Ancak, Kafka kümesi, kullanılabilirliğe öncelik vermek için en az bir kez teslim için yapılandırılmıştı ve bu, tüketici yeniden deneme mantığının kopya ticaret olayları oluşturmasına neden olarak pozisyon hesaplamalarını bozuyordu. Aynı zamanda, okuma modelini gerçek zamanlı maruziyet hesaplamaları için sorgulayan risk yönetimi panosu, uyumlu Oracle 12c veritabanına ODBC köprüleri aracılığıyla senkronize yazma girişiminde bulunduğundan dolayı 300ms gecikme dalgalanmaları yaşıyordu ve bu, 50ms risk eşiğini aşmasına neden oluyordu.
Çözüm 1: Kafka'da tam olarak bir kez anlamlarını etkinleştirin
Ekip, her mesajın atomik olarak onaylandığından ve tüketici ofsetleri ile birleştirildiğinden emin olmak için Kafka'yı, işlem kimlikleri ve idempotent üreticiler ile tam olarak bir kez işleme (EOS) kullanacak şekilde yeniden yapılandırmayı düşündü. Bu yaklaşım, her mesajın protokol seviyesinde kopyalarının önlenmesini sağlayarak uygulama kodu değişiklikleri olmaksızın kopyaların yerel olarak işlenmesinin yanı sıra partitionlar içinde sıkı sıralama garantilerini sürdürmeyi içeriyordu. Ancak, dezavantajları engelleyici hale geldi: işlem koordinasyonu aşırı yükü her mesaj için 18-25ms gecikme ekledi ve ZooKeeper bağımlılığı, yöneticinin seçimi sırasında ticaret boru hattını durduracak bir tek hata noktası oluşturdu. Dahası, bu, temel Oracle ODBC darboğazını ele almıyor, yalnızca kopyaları önleme karmaşıklığını yukarı kaydırıyordu.
Çözüm 2: Cassandra'yı ara bir sıcak depolama olarak dağıtın
Alternatif olarak, Kafka ile Oracle arasında bir Cassandra kümesi yerleştirerek yüksek hızlı bir tampon görevi görmesi önerildi. Apache Spark Streaming, yazımları gece boyunca Oracle'a toplu halde yazmadan önce Cassandra akışında pencereleyerek kopya önleme uygulayacaktı. Avantajları, Cassandra'nın milisaniye gecikmesi ile yüksek yazma verimliliğini idare edebilmesi ve gerçek zamanlı işlemeyi uyumlu depolamadan ayırabilmesidir. Ancak, dezavantajları önemli operasyonel riskler getirdi: iki farklı depolama sistemini sürdürmek, ağ bölünmeleri sırasında split-brain senaryoları yarattı ve SEC denetçileri ara değişken mutable depolamanın değişmez denetim izleri için güvenilir bir kaynak olabileceğine dair şüphelerini dile getirdi. ACID özelliklerini sağlama karmaşıklığı bu projeyi tehdit ediyordu.
Çözüm 3: İstemci tarafında idempotans ile Redis okuma modelleri ve Debezium CDC
Seçilen çözüm, olay işleyicileri içinde bileşik doğal anahtarlar (toplu kimlik + sıra numarası) kullanarak istemci tarafında idempotans uyguladı ve böylece kopya Kafka mesajlarının tanınması ve durum değişikliği olmaksızın atılması sağlandı. Gecikme gereksinimi için, ekip, mikro hizmetlerle yan yana yerleştirilmiş Redis kümeleri dağıtarak olay projeksiyonlarını kullanarak okuma modellerini materyalleştirdi ve risk hesaplamaları için alt-10ms sorgu yanıt sürelerine ulaştı. Performans üzerinde olumsuz bir etkisi olmadan Oracle uyumluluk gereksinimlerini karşılamak için, olay deposunun PostgreSQL arka uç veritabanından değişiklikleri yakalamak ve bunları asenkron olarak Oracle'a akıtmak için Debezium'u uyguladılar, denetim raporlaması için nihai tutarlılığı kabul ederek ticaret işlemleri için güçlü tutarlılığı korudular.
Bu yaklaşım, kopya olay riskini altyapı kısıtlamaları yerine uygulama mantığıyla ele aldığı, hafıza içi önbellekleme ile agresif gecikme SLA'sını karşıladığı ve gerçek zamanlı kritik yoldan ayırarak eski Oracle yatırımına saygı gösterdiği için başarılı oldu. Sonuç olarak, sistem, ortalama 12ms okuma gecikmesi ile saniyede 150.000 olay işleyen, altı aylık işlem süresinde sıfır kopya ticaret tespit edilen ve veri değişmezliği veya izlenebilirliği konusunda bulgu olmadan tam SEC uyumluluğu doğrulaması geçti.