Cómo lidiar con duplicados en webhooks por idempotencia?

[Jacob39]

Estaba revisando el webhook de nuestro sistema de pagos y me encontré con un escenario raro: a veces llegan dos eventos casi idénticos por la misma transacción, con milisegundos de diferencia. Nuestra lógica para evitar duplicados se basa en el ID del evento, pero estos traen IDs diferentes. Me pregunto si es un problema de idempotencia en su lado o si debemos cambiar nuestro enfoque y aceptar que algunos eventos son inherentemente duplicados. ¿Alguien más ha lidiado con algo así?

[Chloe40]

Puede ser un tema de idempotencia en alguno de los extremos. Sugiero correlacionar por el ID de transaccion y un hash del payload y aplicar una ventana de deduplicacion de sesenta segundos. Si llega un segundo evento para la misma transaccion dentro de esa ventana descartalo y registra el motivo. Así no dependes solo del ID del evento.

[Nora.G]

No me trago que dos IDs distintos representen exactamente la misma accion. Podría ser un fallo del gateway o reintentos del emisor. ¿Qué tan confiables son esos milisegundos entre eventos?

[Eleanor_C]

Desde la lectura dos notificaciones en milisegundos confunden el tablero. Quizás convenga exponer una única secuencia por transacción y un origen claro para entender si es duplicado o no. Idempotencia de verdad no solo la palabra sino la practica.

[Camila.H]

¿Vale la pena perseguir duplicados a nivel de webhook si el sistema de pagos ya evita cargos dobles? Tal vez convenga diseñar para duplicados ocasionales y centrar esfuerzos en la idempotencia en el consumidor.

[Zoey_W]

En mi experiencia se resuelve con una clave de correlación y un estado de la transacción. Si llega un segundo webhook para una transacción ya completada se ignora. Esto mantiene la semántica de idempotencia.

[EvelynAG]

Me suena a que hay que mirar la tolerancia a fallos. A veces el costo es alto si dependes de que el webhook venga único. La palabra idempotencia aparece cuando conviene pero hay que ver practicas como un idempotent consumer y un historial claro.

[Layla54]

Quizá convenga una DLQ para duplicados y un buffer de procesamiento eso entra en arquitectura de colas.