Tratar un resultado de integración incierto como desconocido, no como fallido
Un timeout no dice nada sobre si el receptor confirmó la operación. Modelar ‘desconocido’ como estado propio, resolverlo por clave de petición y solo entonces reintentar o darlo por fallido.
Elaborado de forma independiente. No contiene detalles de implementación, nombres internos ni cifras de ningún empleador o cliente.
01Contexto
Un CRM envía peticiones de creación de clientes y de pedidos a un ERP a través de una capa de integración. Con carga, algunas llamadas agotan el tiempo de espera cuando el ERP ya ha confirmado la operación. La integración las marca como fallidas; los usuarios o los reintentos automáticos las reenvían, y aparecen clientes legales y pedidos duplicados. Otros timeouts sí son fallos reales, y para quien llama ambos casos son idénticos.
02Factores de decisión
- F01
Deshacer un cliente legal duplicado es caro
- F02
Los usuarios necesitan un estado honesto mientras el resultado es incierto
- F03
Se puede consultar al receptor por una clave de petición externa
- F04
Los fallos transitorios siguen necesitando reintentos
03Opciones consideradas
Tratar el timeout como fallo y reintentar
Receptores idempotentes por diseño
Coste: Un duplicado cada vez que el receptor ya había confirmadoTratar el timeout como éxito
Nada que importe
Coste: Huecos silenciosos: pedidos contra clientes que no existenUn estado Desconocido, resuelto por clave de petición
Receptores que no son idempotentes, o no del todo
Coste: Requiere una clave de petición consultable, un proceso de resolución y un responsable04Decisión
Cada petición saliente lleva una clave de idempotencia ligada a la petición de negocio y un ID de correlación. Un timeout o una respuesta perdida pasa la petición a Desconocido, no a Fallido. Antes de cualquier reintento, la capa de integración busca la petición en el receptor por su clave: si aparece, se confirma; si no, se reintenta con la misma clave; si sigue sin resolverse agotado el presupuesto de reintentos, se escala a un responsable con nombre. Los usuarios ven “confirmando el resultado”, nunca una invitación a pulsar el botón otra vez.
05Consecuencias
- Desconocido pasa a ser un estado de negocio monitorizado, con antigüedad y responsable.
- Los reintentos son seguros: la misma clave no puede crear dos veces.
- La conciliación cierra los Desconocidos que el proceso de resolución no puede cerrar.
- El receptor debe permitir la consulta por clave de petición externa, o la capa de integración mantiene un registro de lo enviado.
06Cuándo revisarla
El receptor garantiza la creación idempotente por clave.
La operación pasa a ser de solo lectura o idempotente por naturaleza.