El silencio no demuestra que no haya ocurrido nada
Una aplicación envía un pedido, el servidor lo guarda y la respuesta se pierde. El cliente ve un error y vuelve a intentarlo. Si cada intento crea un pedido, un fallo de comunicación se convierte en un problema de negocio. «Repetir hasta que funcione» no basta.
Un tiempo de espera limita cuánto espera quien llama; no deshace automáticamente lo ejecutado en el servidor remoto. La interfaz debe distinguir un fallo confirmado de un resultado desconocido. Cuando haga falta, permite consultar el estado antes de crear otra operación.
Da identidad a la operación
Una clave de idempotencia identifica la misma intención entre intentos. El servidor debe guardarla, reconocerla y asociarla al resultado. Generar otra clave en cada reintento anula su propósito. También hay que gestionar peticiones simultáneas para impedir dos creaciones.
Esto no significa ignorar diferencias. La API debe tratar explícitamente una misma clave con otro importe o destinatario. Define cuánto se conserva y qué ocurre después. La garantía depende del contrato y de la implementación, no del nombre de la cabecera.
Menos reintentos pueden mejorar la recuperación
Ante fallos transitorios, limita los intentos y aumenta los intervalos. Una variación aleatoria, llamada jitter, evita que todos reintenten a la vez. Esperar no suele corregir credenciales inválidas ni datos rechazados. Respeta las indicaciones y los límites del servicio.
Vigila también las capas: reintentos descoordinados en aplicación, biblioteca e intermediario multiplican la carga. Decide dónde controlarlos y sigue los resultados desconocidos. El mensaje al usuario debe ofrecer un siguiente paso sin afirmar un fallo todavía incierto.
Prueba la respuesta que nunca llega
En pruebas, simula una respuesta perdida tras guardar la operación. Repite con la misma clave y confirma que solo hay un resultado. Prueba también intentos simultáneos y una clave reutilizada con datos distintos. Documenta primero el comportamiento esperado: preservar la intención del usuario.
Fuentes y lecturas complementarias
- AWS — Retry with backoff pattern ↗
- AWS Builders’ Library — Timeouts, retries, and backoff with jitter ↗
Fuentes consultadas el 24 de octubre de 2026. Los ejemplos numéricos y los escenarios son ilustrativos.
¿Ponemos este conocimiento en práctica?
Podemos trabajar juntos en el reto de tu equipo o en tu próximo proyecto.
Hablar con Calembe ↗