Haz que las acciones del agente sean seguras para reintentar: clave, deduplicación y registro de cada efecto secundario
Las acciones del agente seguras para reintentos necesitan una clave de idempotencia, una verificación de deduplicación y un registro de resultados confirmados antes de actualizar cualquier ticket, correo o registro.
Un agente de soporte recibe un webhook, crea un ticket y luego la entrega se repite. El cliente ve tickets duplicados. El agente también puede enviar correos duplicados o actualizar el mismo registro de nuevo. El problema es la ejecución duplicada.
Los agentes que consumen eventos de colas de mensajes o infraestructura de webhooks operan con semántica de entrega al menos una vez, por lo que el mismo evento puede llegar de nuevo. No suprimas los reintentos de webhooks.
Un agente que envía correos, actualiza registros o llama a APIs de pago puede duplicar un efecto secundario real cuando la idempotencia falla. Mantén los reintentos. Haz que cada efecto secundario sea seguro de repetir.
Los manejadores seguros para reintentos asignan clave, deduplican y registran
La idempotencia significa que el mismo evento produce el mismo resultado confirmado, no otra acción. El operador necesita una identidad de evento estable que sobreviva a reintentos, reentregas y reproducciones manuales.
Asigna la clave de idempotencia antes de la ejecución. Tóma del evento de origen, no del agente. Un ID de evento de origen puede anclarla. La clave debe ser estable entre reintentos.
Verifica la clave contra un almacén de deduplicación antes de ejecutar la acción. Si la clave ya tiene un resultado confirmado, devuelve ese resultado. No crees otro ticket, no envíes otro correo ni actualices el registro de nuevo.
Escribe el resultado confirmado en un registro de efectos secundarios antes de devolver éxito. Registra la clave, la acción, el destino y el resultado. Si el proceso falla después de la acción externa pero antes del registro, el siguiente reintento debe poder detectar el resultado confirmado.
En un patrón de acuse y posterior procesamiento, los reintentos son seguros cuando el acuse de recibo es idempotente. El agente puede acusar recibo y luego procesar el evento desde una cola. El acuse no debe crear otra acción.
Los timeouts y la observabilidad mantienen los reintentos seguros
Un manejador de webhooks de tres operaciones puede ejecutarse con una cola duradera, reintentos con backoff, una clave de idempotencia, observabilidad a nivel de evento y un timeout razonable. Para un agente de soporte que crea tickets, envía correos o actualiza registros, la lista de verificación siguiente es el conjunto mínimo.
- Asigna una clave estable a cada evento antes de la ejecución.
- Verifica esa clave contra un almacén de deduplicación antes de ejecutar la acción.
- Escribe el resultado confirmado en un registro de efectos secundarios antes de devolver éxito.
- Haz que el acuse de recibo sea seguro de repetir.
- Establece un timeout que coincida con la operación segura más lenta.
- Rastrea cada evento desde el recibo hasta el resultado confirmado.
La clave detiene las acciones duplicadas en la fuente. La verificación de deduplicación detiene la ejecución repetida. El registro le da al siguiente reintento un resultado confirmado con el que comparar. Sin él, el agente no puede saber si la acción se confirmó.
Un manejador lento puede desencadenar otra entrega. Hookdeck establece un timeout de entrega de webhooks predeterminado de 60 segundos, y un destino puede configurarse para permitir hasta 15 minutos. Elige el timeout según la operación segura más lenta, no la ruta feliz más rápida.
La observabilidad debe mostrar el ID del evento, la clave, el resultado de deduplicación y el resultado confirmado. Si ocurre un reintento, el operador debe ver si se omitió, se reprodujo o falló. Esa visibilidad permite al operador encontrar el duplicado antes que el cliente.
La entrega basada en eventos es más rápida pero no segura para reintentos
Las arquitecturas de agentes basadas en eventos pueden reducir la latencia del sistema entre un 70% y un 90% en comparación con equivalentes basados en polling y no usan cómputo mientras están inactivos. Un agente de polling que verifica cada 5 minutos desperdicia más del 99% de su uso de recursos cuando los cambios son infrecuentes. La ganancia de eficiencia no elimina la entrega duplicada.
La entrega basada en eventos no cambia la regla de seguridad. Si el agente puede crear tickets, enviar correos o actualizar registros, trata cada escritura externa como un efecto secundario que puede repetirse.
Envía el mismo evento de nuevo. La entrega repetida no debe crear otro ticket, enviar otro correo ni actualizar el registro. Si lo hace, el manejador no es seguro para reintentar.