Por Nicho Agencia Digital · Publicado el
Distingue entrega, evento y operación de negocio
Una entrega es un intento de transportar la notificación. El evento describe algo que ocurrió y la operación de negocio es lo que tu sistema decide hacer. Dos entregas del mismo evento no deberían generar dos pedidos; dos eventos distintos tampoco deberían duplicar una misma orden si ambos describen la misma operación.
Stripe documenta que los webhooks pueden repetirse y llegar fuera del orden en que se generaron. Ese comportamiento concreto debe revisarse en cada proveedor. No asumas que un identificador o una política de reintentos funcionan igual en todas las plataformas.
Define la identidad con su contexto: proveedor, cuenta, entorno y evento. Para el pedido, puede ser necesaria otra clave: cuenta de origen y número de orden. Reutilizar solo un correo o una marca de tiempo puede confundir operaciones legítimamente distintas.
Recibe rápido, pero conserva lo necesario para continuar
Como diseño de referencia, valida la autenticidad de la solicitud según el mecanismo oficial del proveedor y revisa su estructura. Después guarda el evento de forma duradera o confirma su incorporación a una cola persistente. La respuesta exitosa de recepción debe llegar cuando el sistema pueda continuar aunque el proceso se reinicie.
Marca estados distintos para recibido, en proceso, completado y pendiente de revisión. Haber recibido un evento no demuestra que su efecto se haya aplicado. Si falla el almacenamiento inicial, responder éxito puede hacer que el proveedor deje de intentar una entrega que aún no se conserva.
Evita guardar secretos o datos personales innecesarios en registros técnicos. Para investigar suele ser más útil un identificador correlacionable, un estado y un error depurado que una copia indiscriminada de todo el contenido.
Protege la acción ante dos trabajadores simultáneos
Consultar primero si el evento existe y crearlo después deja una ventana: dos procesos pueden consultar al mismo tiempo y concluir que deben actuar. El equipo técnico debe diseñar una reserva atómica, una restricción única o un mecanismo equivalente que controle esa concurrencia.
Cuando el registro de procesamiento y el pedido viven en la misma base de datos, evalúa guardarlos dentro de una transacción. Para acciones externas, como enviar una orden a otro proveedor, define cómo registrar la intención, transmitirla y reconciliar el resultado. Un patrón de bandeja de salida transaccional puede ayudar, pero su implementación también necesita controles en el destino.
Si el destino admite claves de idempotencia, conserva la misma clave para reintentar la misma operación. Si no las admite y la respuesta es incierta, consulta el resultado o deriva a revisión antes de repetir una acción con consecuencias.
Ejemplo hipotético y pruebas que deberían fallar primero
Una tienda recibe dos entregas del evento “pedido confirmado” para la orden PED-58. El diseño esperado permite conservar ambos intentos como evidencia, asociarlos a una sola operación y crear un único pedido interno. Si un trabajador se detiene después de guardar el pedido, otro debe poder verificar lo sucedido antes de continuar.
- Envía el mismo evento dos veces de forma consecutiva.
- Envíalo simultáneamente para probar la concurrencia.
- Interrumpe el proceso antes y después de guardar el pedido.
- Simula una respuesta perdida del servicio externo.
- Entrega una actualización antigua después de una nueva y verifica que no deshaga el estado correcto.
- Comprueba que dos pedidos diferentes del mismo cliente siguen siendo aceptados.
Evalúa pedidos, reservas y notificaciones, además del código de respuesta del webhook. El duplicado puede aparecer en cualquiera de esos efectos.
Define límites y recuperación
Documenta durante cuánto tiempo se conservan las claves de deduplicación, cómo se recupera un evento detenido y quién puede reprocesarlo. Ese periodo depende de los reintentos, reenvíos y necesidades de auditoría del proceso. Al borrar el historial demasiado pronto, una entrega antigua podría volver a aceptarse.
La idempotencia reduce un tipo de riesgo; no confirma que todos los eventos hayan llegado ni resuelve por sí sola conflictos de inventario. Incluye conciliaciones y alertas para operaciones incompletas. La meta verificable es un efecto correcto por operación, dentro de las condiciones probadas, sin prometer ejecución perfecta ante cualquier fallo.
Completa este diseño con una ruta para reintentos y revisión de fallos de integración.
El siguiente paso
Revisemos qué eventos recibe tu operación y en qué punto podrían repetirse pedidos, reservas o notificaciones.
Automatización de procesos comerciales · Conversar sobre tu proyecto ↗
Fuentes y alcance
Fuentes consultadas el 11 de octubre de 2026. Las recomendaciones de proceso son propuestas editoriales de Nicho; los ejemplos identificados como hipotéticos no representan resultados de clientes.
Contenido preparado con asistencia de IA y comprobaciones automáticas. No sustituye una evaluación de tu implementación ni garantiza resultados. Escríbenos si encuentras algo que debamos corregir.