La respuesta puede perderse
Piensa en una petición para crear un pedido: el servidor puede completar la operación y el cliente no recibir la respuesta. Si el cliente repite la petición, el resultado depende del contrato de la API. Esa ambigüedad debería formar parte del diseño inicial de una operación con efectos de negocio.
Define un contrato de repetición
Una propuesta para la creación de pedidos es que el cliente aporte una clave de idempotencia estable para la misma intención. El servidor debe definir el alcance de la clave, su caducidad y qué sucede si llega con un contenido diferente. Guardar una clave sin coordinarla con el resultado de negocio deja condiciones de carrera por resolver.
Limita el trabajo adicional
Los reintentos pueden agravar una sobrecarga. La documentación de AWS recomienda limitar intentos y usar esperas crecientes; el jitter añade variación para evitar que muchos clientes reintenten a la vez. La política debe distinguir fallos transitorios de errores que no se arreglarán repitiendo la petición.
Haz visible el presupuesto
Para un flujo concreto, proponemos documentar el tiempo total disponible, qué capa reintenta y cuántos intentos permite. Comprueba también las políticas de los clientes y SDK utilizados. Varias capas reintentando de forma independiente pueden generar mucho más tráfico del esperado.
Prueba el caso incómodo
Incluye una prueba en la que el servidor confirma la operación pero se pierde la respuesta. Envía después dos intentos concurrentes con la misma clave y verifica el resultado de negocio. Añade métricas de reintentos, duplicados detectados y agotamiento del presupuesto para observar el comportamiento en producción.