Timeout
Qué es
Un timeout limita cuánto tiempo un actor espera una operación o una fase local antes de considerar agotada esa espera. Puede aplicarse a adquirir una conexión, establecerla, recibir datos o completar un intento. Su alcance debe estar definido: distintos límites pueden proteger recursos diferentes.
Timeout no implica cancelación remota garantizada ni prueba de que la operación falló. Puede haberse perdido la solicitud, estar todavía ejecutándose o haberse confirmado su efecto sin que la respuesta llegue a tiempo. El resultado observado por el caller es una espera vencida, no una demostración sobre el estado remoto.
deadline expresa hasta cuándo la operación completa dispone de presupuesto. Un timeout para un intento puede ayudar a cumplir ese deadline, pero renovar el mismo timeout en cada fase o reintento no conserva automáticamente el límite total.
Qué problema resuelve
Esperar indefinidamente puede retener conexiones, memoria, workers y capacidad para atender otras solicitudes. Si una dependencia se vuelve lenta, muchas esperas simultáneas pueden agotar al caller antes de que se declare un fallo.
Un timeout permite terminar esa espera y liberar los recursos que realmente controla su implementación. No libera automáticamente locks, trabajo remoto ni una tarea que ignora la cancelación. AWS Builders’ Library relaciona los tiempos de espera con recursos retenidos y advierte que una respuesta ausente no demuestra ausencia de efectos. Timeouts, retries, and backoff with jitter.
Cómo funciona y qué cubre
El diseño debe indicar cuándo empieza el contador y qué lo termina. Un read timeout puede medir inactividad entre lecturas y reiniciarse con cada fragmento; eso no siempre limita la duración de toda la respuesta. Un connection timeout tampoco necesariamente incluye resolución de nombres, negociación de seguridad o espera en un pool.
Un límite útil debe cubrir las fases relevantes o combinarse con un presupuesto total. Que una biblioteca tenga una opción llamada timeout no permite asumir su semántica. La espera en colas locales también consume tiempo aunque todavía no se haya enviado ningún byte.
Cuando vence, el caller puede dejar de esperar, cerrar recursos locales y solicitar cancelación. El receptor debe cooperar para detener el trabajo que inició. gRPC distingue esa señal de la responsabilidad del handler de interrumpir su cómputo; el transporte no puede detener arbitrariamente toda la lógica de aplicación. gRPC: Cancellation.
Cancelar tampoco revierte un commit ya realizado. El protocolo necesita un resultado durable consultable o una operación segura de repetir si ese desenlace puede quedar incierto.
Elección del valor y false timeouts
Un valor demasiado pequeño produce false timeouts: el caller abandona una operación que podría completar dentro de la latencia aceptable del negocio. Eso puede elevar reintentos y carga, haciendo más lenta la dependencia. Uno demasiado grande prolonga ocupación y demora detectar que ya no conviene esperar.
La elección necesita evidencia sobre distribución de latencia, fases cubiertas y presupuesto del caller. Percentiles altos son una entrada, no un valor universal: pueden variar por tipo de operación, tamaño de respuesta, región, conexiones nuevas o calentamiento del servicio.
Supongamos que una lectura suele terminar en 60 ms y que ciertas conexiones nuevas requieren 180 ms. Un límite de 80 ms que también incluya establecer conexión castigaría esas solicitudes aunque el trabajo remoto sea normal. El ejemplo no recomienda un número: muestra por qué medir solo consultas con conexiones ya abiertas es insuficiente.
El timeout tampoco debería crecer sin límite para esconder una degradación. Ajustarlo requiere observar si mejora la utilidad de las respuestas o solo conserva más trabajo pendiente.
Ejemplo y resultado desconocido
Order Service solicita una reserva a Inventory Service con identidad reserve-order-42. Inventory confirma la reserva a los 170 ms, pero la respuesta no llega antes del timeout local de 200 ms.
Si el caller crea otra identidad y pide una nueva reserva, puede descontar dos unidades. Consultar el resultado de la identidad original o repetir bajo un contrato de idempotency permite recuperar la intención sin inventar que el primer intento no ocurrió.
Una señal de cancelación posterior puede llegar demasiado tarde para impedir esa reserva. Si la operación debe abandonarse por razones de negocio, hacen falta reglas para liberar lo reservado; no basta con cerrar el socket.
Failure scenarios
| Situación | Riesgo y respuesta de diseño |
|---|---|
| Tiempo de pool o DNS fuera del límite | La espera real supera lo que el caller creía limitar. |
| Respuesta perdida después de commit | Conservar identidad y resolver el resultado incierto. |
| Trabajo remoto continúa después de vencer | Evitar acumular intentos superpuestos sin controlar sus efectos. |
| Timeout muy corto durante una degradación | Reintentos amplifican carga y producen más expiraciones. |
| Timeout muy largo con muchas solicitudes | Recursos locales permanecen ocupados mientras cae el progreso. |
Timeouts repetidos pueden aportar evidencia para circuit-breaker, pero un timeout mal calibrado también puede abrirlo contra una dependencia sana. Medir por separado esperas vencidas, cancelaciones solicitadas y resultados posteriores ayuda a localizar la frontera del fallo.
Cuándo usarlo y límites
Usarlo en esperas que necesitan un límite operativo, especialmente llamadas remotas y adquisición de recursos. Coordinarlo con deadline para que fases y reintentos no excedan el presupuesto completo. El caller puede terminar sin que el efecto remoto haya desaparecido: esa posibilidad debe formar parte de su contrato.
No tratarlo como un detector infalible de procesos muertos ni como autorización automática para repetir escrituras. retry decide si conviene volver a intentar; at-least-once explica por qué recuperar una entrega puede implicar repetición. Un trabajo durable que ya se aceptó puede seguir teniendo una obligación pendiente aun cuando el cliente original dejó de esperar.
El MOC resilience-patterns conecta los límites de espera con decisiones sobre reintentos y admisión. El patrón aporta control local del tiempo; su utilidad depende de conocer qué espera limita y qué responsabilidad continúa después de vencer.