Tek başına geliştirilen bir sörf tahmini uygulamasını işletirken yaşanan push bildirimi çift gönderim vakası ve çözüm süreci özetleniyor.
Belirli koşullar sağlandığında kullanıcıya bildirim gönderen yaygın bir özellikte, sunucu her yeniden dağıtıldığında
"zaten gönderilmiş bildirim"in yeniden gitmesi sorunu tekrarladı.
■ Sorun
- Her yeniden dağıtım/yeniden başlatmada aynı bildirim tekrar gönderiliyordu
- Lokal ortamda yeniden üretmek zordu; sorun yalnızca dağıtımdan hemen sonra ortaya çıktığı için nedeni bulmak güçtü
■ Neden
- Çift gönderimi önleme (
dedup) durumu yalnızca sunucu belleğinde tutuluyordu - Yeniden dağıtımda süreç baştan ayağa kalkınca bu durum tamamen sıfırlanıyor → "gönderilmemiş sayılıyor" ve yeniden gönderiliyordu
■ Çözüm
dedupanahtarlarını açılışta DB'den yeniden dolduran (seed-on-boot) bir yapıya geçildi → yeniden dağıtımdan sonra da durum korunuyor- Yalnızca "koşulun değiştiği anda bildirim" yaklaşımının, bu aradaki ağırlık değişimlerini kaçırdığı da fark edildi
→ nedenleri biriktirip kademeli olarak yükselten (eskalasyon) bir yönteme geçildi - FCM token'ları, cihaz başına 1 adet olacak şekilde düzenlendi (token yenileme ve yinelenen token işleme dahil)
■ Çıkarımlar
- Bildirim
dedupu gibi "yalnızca bir kez gerçekleşmesi gereken" durumu sadece in-memory tutmak, dağıtımı doğrudan hataya dönüştürür - Durumun yaşam döngüsü sürece göre değil, kalıcı depolamaya göre tasarlanmalı
- Tetikleyicileri "geçiş anı" yerine "mevcut durum" temelinde değerlendirmek, kaçırmaları azaltır
Sunucu push/bildirimleri, cron·batch ve çift gönderimi önleme mantığıyla uğraşanlar için yararlı bir gerçek dünya örneği.
Henüz yorum yok.