Veri Kalitesi Hatasına Müdahale & Karantina Yönetimi
Üretim akışlarında şema kontrollerini geçen ancak sözleşme ve semantik kuralları ihlal eden verilerin tespiti, altyapı arızalarından ayrıştırılması, DLQ karantinası, devre kesici (Circuit Breaker) ve tekil anahtar garantili idempotent yeniden işleme kılavuzu.
Bu sayfadaki ve test paketindeki IdempotentOrderLedgerSink, tek bir Node.js sürecinde çalışan bellek içi (In-Memory Map) bir modeldir. Gerçek bir veritabanının (PostgreSQL, BigQuery vb.) ACID işlemlerini, WAL günlüğünü, dağıtık eşzamanlılık kilitlerini (concurrency locks) veya çökme sonrası kurtarma dayanıklılığını test etmez. Bu senaryodaki mükerrer kayıt engelleme kanıtı, hedef saklama katmanında order_id üzerinde tekil anahtar (UNIQUE constraint) ve atomik upsert varsayımına dayanır.
Doğrulayıcı servisin çökmesi veya zaman aşımı durumunda veri durumu kesinlikle UNVERIFIED kalır; asla veri hatası veya geçerli veri olarak etiketlenmez.
İzole bozuk kayıtlar Dead Letter Queue’ya alınır; sistemik 100x ölçek sapmalarında veya toplu bozulmada Adaptif Devre Kesici akışı durdurur.
Hedef tabloda order_id tekil anahtarı sayesinde düzeltilmiş partinin yeniden işletilmesi test edilen senaryoda sıfır mükerrer kayıt ve kuruşu kuruşuna bakiye sağlar.
Operasyonel Karar Matrisi: 7 Temel Soru
Veri kalitesi anomalisi tetiklendiğinde nöbetçi mühendisin (On-Call) ve veri ekibinin izlemesi gereken standart işletim prosedürü (SOP):
Canlı İhlal vs Altyapı Kesintisi Ayrımı
Üç farklı arıza türü kesin çizgilerle ayrıştırılmalıdır: (1) Yayın öncesi şema kontrolünün PR aşamasında reddetmesi, (2) Canlı üretim verisinin ODCS sözleşmesini ihlal etmesi, (3) Doğrulama servisinin erişilemez olması (HTTP 503 / Timeout). Doğrulama servisi çöktüğünde veri asla "geçersiz" veya "geçerli" sayılamaz; durumu UNVERIFIED olarak kalır ve Yeniden Deneme Kuyruğuna (Retry Queue) aktarılır. Deneme sınırının (3 retry) aşılması verinin hatalı olduğunu kanıtlamaz; yalnızca doğrulanamadığı için eskalasyon gerektirir.
Tüketici Kataloğu ve Aşağı Akış Tespiti
Orders sözleşmesini tüketen somut sistemler taranır: Fatura API (OrderBillingConsumer), Finans Veri Ambarı (BigQuery Orders Table) ve Müşteri Sadakat Servisi. İhlalin downstream tablolara yazılıp yazılmadığı, ters bakiye üretip üretmediği veya BI gösterge panellerini kirletip kirletmediği derhal tespit edilir.
Karantina, Fail-Fast ve Devre Kesici
• RECORD_QUARANTINE: Tekil hatalı kayıt DLQ’ya alınır; temiz kayıtlar işlemeye devam eder.
• FAIL_FAST_HALT: İlk hatada işlemeyi durdurur; önceki işlenmiş kayıtlar ambar defterinde kalır (Partial Commit), kalan kayıtlar UNPROCESSED_HALTED olarak raporlanır. Atomik rollback değildir.
• ADAPTIVE_CIRCUIT_BREAKER: Hata oranı eşiği aşıldığında veya 100x ölçek sapması gibi sistemik hatalarda boru hattını otomatik keser; kalan kayıtlar değerlendirilmeden durdurulur.
Roller ve Müdahale Sorumlulukları
Incident Commander (A): Müdahaleyi koordine eder, durdurma ve yayın kararlarını onaylar.
Producer Squad (R): Kaynak mikroservisi inceler, kök neden yazılım yamasını hazırlar.
Consumer Teams (C): Aşağı akış mutabakatını yapar, ambar tutarlılığını onaylar.
Data Platform / SRE (S): DLQ yönlendirmesi, boru hattı yeniden başlatma ve telemetriyi yürütür.
Kaynak Düzeltmesi vs Sözleşme Evrimi
Hata yazılım bug’ı kaynaklıysa (örn. 129.99 yerine 12999 sent gönderilmesi veya negatif tutar) kesinlikle VERİ DÜZELTMESİ (Data Remediation) yapılır; kural esnetilmez. Eğer yeni bir meşru iş modeli doğduysa (örn. yeni bir ödeme tipi APPLE_PAY eklendiyse), sözleşme Expand & Contract protokolüyle evrimleştirilir (Rule Fix).
Kanonik Eşitlik, Zaman Damgası & Çelişki Ayrımı
Düzeltilen kayıtların yeniden oynatılması, iş içeriği ile işlem metadatasını kesin çizgilerle ayıran kanonik karşılaştırıcı (compareOrderEventPayloads) ile güvenceye alınır. Olay kimliği altında değişmez kabul edilen 8 kanonik alan (order_id, customer_id, amount_usd, payment_method, status, created_at_utc, discount_code, tracking_number) karşılaştırılır. Karşılaştırma JSON anahtar sırasından bağımsızdır. Avro/ODCS şemasında varsayılanı null olan alanlar için eksiklik (undefined) ile açık null eşdeğer kabul edilir; ancak null iken promosyon kodu eklenmesi veya created_at_utc değerinin 1 saat dahi kaydırılması mutasyon sayılarak PAYLOAD_CONFLICT ile reddedilir. Ayrıca çok durumlu olay yaşam döngüleri için üretim sistemlerinde (order_id, event_type, version) bileşik anahtarları şarttır.
Vaka Kapatma Şartları ve Postmortem Kaydı
Bir veri kalitesi vakasının kapatılabilmesi için: (1) DLQ birikiminin ve gecikmesinin sıfırlanması, (2) Ambar muhasebe defterinde yeniden işlenen toplam ciro ve sipariş sayısının ($375.47 / 4 sipariş) matematiksel doğrulanması, (3) Üretici yazılım yamasının canlıya alınması, (4) Postmortem vaka kaydının (DQ-INCIDENT-YYYYMMDD-XXX) tamamlanması zorunludur.
Üçlü Yayın (Triad) Ekosistem Bağlantıları
Kurtarma & Olay Müdahalesi (Reliability)
PostgreSQL PITR veri tabanı kurtarma tatbikatı ve replikasyon gecikmesi (lag) acil müdahale rehberi.
Güvenli Değişiklik & Sürüm Yönetimi
Schema Registry BACKWARD_TRANSITIVE kontrolü, Avro uyumluluk matrisi ve Expand & Contract dağıtım protokolü.
Veri Kalitesi & Gözlemlenebilirlik Araçları
Great Expectations, Soda Core, Monte Carlo ve Confluent Schema Registry araç karşılaştırması.