Entegrasyon kodunun asıl sınavı ilk başarılı istek değil, ağ kesildiğinde ve aynı olay ikinci kez geldiğinde verdiği tepkidir. Sipariş ve durum değişikliklerini alırken gecikme, güvenilirlik ve API limitlerini dengeleyin.
1. Olay tabanlı bildirim
Olay tabanlı bildirim kayıtlarında erişim anahtarı, müşteri adresi veya tam istek gövdesi tutmayın. Teşhis için işlem kimliği, sağlayıcı yanıt kodu, süre ve maskelemiş alanlar genellikle yeterlidir. Böylece log yararlı kalırken yeni bir veri güvenliği riski oluşturmaz.
2. Periyodik sorgu
Aynı sipariş olayı iki kez gelebilir. Periyodik sorgu katmanında harici sipariş numarasını ve kanal bilgisini birlikte benzersiz kabul etmek, ikinci olayın yeni sipariş açmasını önler. Yine de güncel durum bilgisinin işlenip işlenmeyeceği ayrıca değerlendirilmelidir.
3. Kaçan olayları tamamlama
Kaçan olayları tamamlama için alarm eşiğini yalnız hata sayısına bağlamayın. Normalde dakikada yüz işlem alan bir bağlantının birden sıfıra düşmesi de sorundur. Başarı oranı, kuyruk yaşı ve son başarılı işlem zamanı birlikte izlendiğinde sessiz kesintiler daha erken fark edilir.
4. İzleme metrikleri
İzleme metrikleri tasarlanırken mutlu yolun yanına en az üç durum ekleyin: zaman aşımı, yetki hatası ve geçersiz veri. Her biri aynı şekilde tekrar denenmemelidir. Yetki hatası insan müdahalesi isterken geçici ağ hatası kuyrukta yeniden işlenebilir.
Canlı öncesi teknik doğrulama
Notlarınızı saklayın ve bir sonraki yoğun günde yeniden karşılaştırın. Gerçek iyileşme, ekip baskı altındayken anlaşılır.
1 ay ücretsiz kullan