Detrás de un error intermitente del tipo 'no healthy upstream' no siempre está la causa que parece más obvia. Este artículo analiza un caso real en un backend de búsqueda donde la explicación inicial apuntaba a la limitación de CPU, pero las pruebas desmontaron esa hipótesis: no había trabajos intensivos dentro de los pods, las latencias presentaban un patrón plano contra el timeout del balanceador y los fallos aparecían sin seguir versiones ni instancias concretas.
La verdadera responsable era una dependencia lenta del almacén de datos. La combinación de llamadas sin timeout y reintentos ante timeouts hacía que cada petición lenta ocupase un worker durante decenas de segundos. Aplicando la Ley de Little (L = λW), el autor muestra cómo un aumento de tres órdenes de magnitud en W puede saturar un pool fijo de workers. Los workers bloqueados en I/O retenían también las comprobaciones de salud, lo que provocaba que el balanceador retirase instancias y, en cascada, dejase sin opciones al siguiente intento.
Además, el tiempo total de reintentos podía superar el plazo del balanceador, generando trabajo desperdiciado que seguía ocupando slots. La recuperación espontánea no era síntoma de resiliencia, sino de un fallo metastable a punto de enquistarse. La solución fue pequeña y quirúrgica: añadir un timeout explícito a cada llamada al datastore, elegido a partir del p99.9 sano y muy por debajo del plazo del balanceador, y acotar los reintentos para que ninguna petición pueda secuestrar un worker indefinidamente.