Qué hacer con un webhook que llega fuera de orden
Un webhook tardío no debe sobrescribir automáticamente un estado más reciente.
Equipo enginerIT· 2 min de lectura
Un webhook tardío no debe sobrescribir automáticamente un estado más reciente. Decide si el evento representa un hecho que debes registrar o una señal para consultar el estado actual. Después aplica una regla por entidad que tolere entregas fuera de orden, sin inventar una secuencia que el proveedor no garantiza.
Distingue orden de llegada, estado actual e historial
La red y los reintentos pueden hacer que una actualización antigua llegue después de una nueva. Tampoco presupongas que la fecha de creación distingue todos los eventos. Stripe advierte que no garantiza el orden y que eventos distintos pueden compartir marca temporal. Guarda recepción y fecha del hecho como datos diferentes. Si el recurso ofrece una versión o secuencia documentada, comprueba su alcance antes de utilizarla como criterio de actualización.
Si el destino solo muestra el estado actual, puedes tratar el evento como aviso para consultar la fuente autorizada y actualizar con su información vigente. Si necesitas el historial de transiciones, guarda los hechos con identidad propia aunque lleguen tarde. Son objetivos diferentes: consultar el estado actual no reconstruye necesariamente todos los cambios intermedios. Documenta qué información perderías y si eso es aceptable para el proceso.
Controla dependencias y concurrencia
Si llega un pago antes de conocer la factura, recupera el objeto relacionado mediante la API cuando esté disponible o conserva el evento pendiente. No crees una factura ficticia para completar la relación. Serializa por entidad o utiliza controles de versión adecuados para que dos trabajadores no decidan sobre el mismo estado antiguo. Una cola ordenada localmente no puede reconstruir por sí sola el orden causal que falta en el origen.
Prueba secuencias que contradigan la llegada
En un ejemplo hipotético, envía confirmación, modificación y después el evento inicial. Verifica que el estado no retrocede y que los hechos necesarios quedan registrados. Añade dos eventos con la misma hora y uno cuyo objeto todavía no se puede consultar. El resultado debe ser una espera acotada o revisión, no la eliminación silenciosa del evento. Define también qué ocurre cuando el estado actual cambió durante tu consulta: conserva la evidencia y vuelve a conciliar según el contrato disponible.
Comprobaciones para cerrar la tarea
- ✓ Un evento inicial tardío no hace retroceder el estado.
- ✓ Dos eventos con la misma hora siguen siendo distinguibles.
- ✓ Una dependencia ausente queda pendiente y visible.
Fuentes y documentación
- Stripe: recepción de webhooks — Documenta firma sobre cuerpo original, duplicados y ausencia de garantía de orden.
- Azure: transacciones de compensación — Deshacer pasos requiere reglas de negocio y consideración de cambios concurrentes.
Aplicarlo en tu empresa
Podemos revisar el entorno y acordar qué actuaciones, validaciones y mantenimiento necesitas.
Conocer el servicio relacionado →