Organicé el incidente de envío duplicado de notificaciones push que viví mientras operaba una app de pronóstico de surf como desarrollador independiente.
Es una función común que envía notificaciones a los usuarios cuando se cumplen ciertas condiciones, pero cada vez que redeployaba el servidor,
el problema de que volvieran a salir notificaciones "ya enviadas" se repetía.
■ Problema
- La misma notificación se enviaba duplicada en cada redeploy/reinicio
- En local casi no se podía reproducir y solo explotaba justo después del deploy, así que encontrar la causa fue complicado
■ Causa
- El estado de prevención de duplicados (dedup) se guardaba solo en la memoria del servidor
- Al redeployar, el proceso arrancaba de nuevo y ese estado se reseteaba por completo → quedaba como "no enviada" y se reenviaba
■ Solución
- Se cambió a una estructura que vuelve a cargar las claves de dedup desde la DB al arrancar (
seed-on-boot) → el estado se mantiene incluso tras un redeploy - También se descubrió que el enfoque de "notificar solo en el momento en que cambia la condición" dejaba pasar cambios de peso en el intervalo
→ se cambió a un método de acumulación de motivos y escalamiento por etapas - Los tokens de FCM se ordenaron bajo el principio de 1 dispositivo = 1 token (incluyendo renovación de token y manejo de tokens duplicados)
■ Lecciones
- Si un estado que "solo debe ocurrir una vez", como el dedup de notificaciones, se deja solo en memoria, el deploy se convierte en un bug
- El ciclo de vida del estado debe diseñarse con base en el almacenamiento persistente, no en el proceso
- Para los triggers, suele haber menos omisiones si se juzgan según el "estado actual" que según el "momento de transición"
Es un caso práctico útil para quienes trabajan con push/notificaciones del servidor, cron·batch y lógica de prevención de duplicados.
Aún no hay comentarios.