Qué señales indican que los webhooks duplican eventos y generan facturas?

[MadisonAA]

Estaba revisando el webhook de nuestro sistema de facturación y me topé con un comportamiento extraño: a veces el payload llega duplicado en un intervalo de pocos milisegundos, pero nuestro endpoint lo procesa como dos eventos distintos. No parece ser un reintento configurado por el proveedor, y nuestra lógica de idempotencia no lo está manejando. ¿Alguien más ha tenido este problema con webhooks que parecen "fantasmas"? Me preocupa que estemos generando facturas duplicadas por esto.

[HarperCH]

Me suena a que el webhook llega dos veces casi de la nada y tu lógica de idempotencia no lo atrapa, quizá porque ambos payloads traen el mismo identificador de evento pero se procesan por separado. Revisa si hay un gateway o proxy que re-emita en fast path o si el id único del evento se mantiene, y añade logs con timestamps y el id de evento para confirmar si son duplicados o dos eventos distintos. ¿Tienen algún webhook gateway o proxy que pueda duplicar entregas?

[LarryFL]

Puede que no sean fantasmas, sino dos eventos que llegan con el mismo contenido por rutas distintas. Asegúrate de inspeccionar el tipo de evento y su ID; a veces el mismo payload se genera desde dos notificaciones diferentes en el sistema de origen. Implementa un deduplicador por ID de evento y, si ya viste ese ID, salta el segundo. ¿Te has fijado si hay dos fuentes de emisión o dos hooks apuntando al mismo endpoint?

[ElizabethW]

Curiosamente, a veces basta con un hash del payload para decidir si ya se vio; si el payload se repite, descartas la segunda entrega. No hace falta magia, solo consistencia en el procesamiento. ¿Te sirve pensar en un idempotent downstream que compare el hash con un store de resultados?

[NathanL]

Propongo una solución basada en idempotency keys por evento: guarda la clave en Redis por X minutos y rechaza cualquier segunda entrega con la misma clave. Añade métricas para ver la tasa de duplicados y una alerta si sube. El reto es el impacto en facturas duplicadas, así que contempla banderas de revisión en caso de dudas. ¿Qué tan rápido quieres reaccionar ante duplicados?

[Zoey9]

Quizá el problema no es técnico sino de contrato entre sistemas. El endpoint debería acordar una entrega exactamente una vez: si dos notificaciones llegan, quizá una de ellas debería ser descartada por diseño. Eso cambia la conversación entre equipos y tests de integración. El término webhook es fácil, pero la práctica es otro juego.

[MasonD]

En producción no siempre funciona todo perfecto; a veces conviene mirar patrones como event sourcing o procesamiento exactamente una vez (exactly-once) para webhooks críticos. Tal vez el camino es introducir un broker que garantice entrega única y ordenar los eventos; mientras, verifica si hay límites de ventana y marca cada intento. El concepto clave aquí sigue siendo webhook, pero su manejo tiene matices.