Timeouts, reintentos e idempotencia

Un servicio caído falla rápido. Si no hay ningún programa escuchando en su puerto, la conexión se rechaza en un milisegundo y el gateway pasa a su plan B. Un servicio lento no avisa nada: la request se queda esperando, y mientras espera ocupa cosas. Memoria para la foto, una conexión abierta, uno de los 16 lugares que el gateway de C01 reserva para requests en vuelo, las que ya entraron y todavía no terminan (su MAX_INFLIGHT). La Ronda (M03) lo resume en una frase: un servicio lento es peor que uno caído.

Un timeout es el tiempo máximo que un programa espera algo antes de rendirse. Cuando vence, el programa deja de esperar, cancela la operación y la trata como una falla. Sin timeout, la espera no tiene fin. Y no es un caso raro: en Python, la biblioteca requests no trae ninguno si no se lo pones, así que una llamada puede quedarse colgada para siempre.

Tres relojes en una sola llamada

Una llamada por la red pasa por etapas, y cada una se puede trabar de forma distinta. Por eso las bibliotecas suelen tener más de un timeout:

• Timeout de conexión (connect timeout): cuánto esperar a que la otra máquina acepte la conexión, el saludo inicial de TCP que viste como handshake. Dentro de un mismo centro de datos ese saludo toma menos de un milisegundo, así que este reloj puede ser corto. Si vence, la request nunca llegó.
• Timeout de lectura (read timeout): ya conectado, cuánto esperar a que llegue el siguiente pedazo de la respuesta. Ojo: en muchas bibliotecas cuenta el silencio entre pedazos, no el total. Un servidor que manda un byte cada 9 segundos nunca dispara un timeout de lectura de 10 s.
• Timeout total: el tope de la llamada completa, de principio a fin. Es el que le importa a quien espera, y el único que acota de verdad cuánto dura todo.

Lo que cuesta esperar de más

La Ley de Little dice cuántas requests hay adentro en promedio: las que llegan por segundo por lo que tarda cada una. Un timeout acota lo que tarda cada una cuando la pieza de abajo se traba, y con eso acota cuántas se juntan. En la lección de async lo contaste: a 500 por segundo, con Triton trabado, un timeout de 150 ms deja 75 llamadas colgadas, y uno de 5 s, 2,500. Ahora mira qué hace eso con los 16 lugares de cada pod (cada una de las 5 copias del gateway en Kubernetes). Cuando están llenos, la siguiente request recibe un 503, el código de «estoy saturado»:

Con 150 ms no caben todas: 19 en vuelo contra 16 lugares, como contaste en la lección de async, y ≈ 16 % recibe un 503. No es una falla del diseño: es el tope haciendo su trabajo, porque cada request recibe su respuesta a tiempo y el caller pasa a su plan B. Sin el tope de 16, con el timeout de 5 s, sería mucho peor: 504 fotos de hasta 10 MB son hasta 5 GB, en un pod de 1 GiB.

Ponerle un timeout a cada llamada no basta: hay que elegirlos bien. Si el caller espera 300 ms y el gateway le da 5 s a Triton, cuando Triton se traba el gateway sigue esperando mucho después de que el caller se fue.

La solución es pensar en un deadline (fecha límite): el momento en que la request entera deja de importar, no una duración por salto. Cada salto calcula cuánto le queda y espera como máximo eso:

timeout de una llamada = min(su propio tope, lo que queda del deadline)

Así, ningún salto espera más de lo que le queda a quien lo llamó. La Ronda lo dice como regla: cada capa se rinde antes que la de arriba.

La cadena de C01

En la lección de async viste la cadena de C01: «300 → 250 → 150 → 100 ms» (M15). Ahora puedes leer por qué tiene cada número:

• 300 ms, el caller. El backend del marketplace se rinde a los 300 ms y muestra el selector de categorías. Es el techo de todo lo demás.
• 250 ms, el deadline del gateway. El gateway se rinde 50 ms antes que el caller. Esos 50 ms le alcanzan para contestar un 504 (Gateway Timeout, «se me acabó el tiempo esperando al de atrás») antes de que el caller abandone.
• 150 ms, la llamada a Triton. Es el tope de esa llamada. Lo que sobra de los 250 se usa para recibir y preparar la foto antes, y para contestar después.
• 100 ms, la fila de Triton. Triton rechaza lo que lleva más de 100 ms esperando su turno, con su política de fila REJECT, porque ya no llegaría a tiempo.

El trabajo zombi

¿Qué pasa si un salto espera más que el de arriba? Que trabaja para nadie. Si el caller ya se rindió y Triton sigue calculando, la GPU gasta tiempo en una respuesta que nadie va a leer. La Ronda le llama trabajo zombi, y en una sobrecarga es justo lo que no sobra: cada lugar de la fila ocupado por un zombi es una request viva que no entra.

Por eso, cuando un salto se rinde, conviene que cancele hacia abajo: cerrar la conexión o mandar un aviso para que el de atrás deje de trabajar. Es la misma cancelación de asyncio.wait_for de la lección de async. En los LLMs importa todavía más: si la cancelación no llega, la GPU sigue generando tokens para nadie.

Un reintento (retry) es volver a mandar una request que falló, con la esperanza de que la segunda vez salga bien. Funciona cuando la falla es pasajera (transient): un pod que se estaba reiniciando, una conexión que se cayó, un servidor saturado unos segundos. No sirve cuando la falla es permanente: si la request está mal hecha, repetirla da el mismo error.

En la lección de probabilidad lo contaste como una réplica en el tiempo: si cada intento falla el 1 % de las veces, por su lado, dos fallan juntos el 0.01 × 0.01 = 0.01 %. La letra chica es «por su lado». Si falló porque el servidor está caído o saturado, el segundo intento lo encuentra igual.

Qué dice cada falla

Cada respuesta HTTP trae un código de estado de tres cifras. Los que empiezan con 4 dicen «el problema es tu request»; los que empiezan con 5, «el problema es mío». Eso ya decide mucho:

El problema del timeout

Fíjate en la fila del timeout. Cuando una llamada vence, desde afuera no sabes cuál de estas tres cosas pasó:

1. La request nunca llegó.
2. Llegó y el servidor sigue trabajando, lento.
3. El servidor ya la hizo y lo que se perdió fue la respuesta.

Las tres se ven igual: silencio. En el caso 3, reintentar repite algo que ya pasó. Si era clasificar una foto, no importa: sale la misma categoría. Si era publicar o cobrar, sale dos veces. Ese problema tiene solución, la idempotencia, y la ves en unas secciones.

Y en el caso 2, el reintento le suma trabajo a un servidor que ya está lento. La Ronda (M03) lo dice sin rodeos: un timeout casi siempre significa «el servidor está lento», no «se perdió un paquete».

C01: ningún reintento en el camino interactivo

Por eso C01 decide que, en el camino de Ana, nadie reintenta. Tiene tres razones. Un segundo intento tendría ≈ 80 ms, después de que el primero no pudo con 150. Triton probablemente sigue saturado, y el reintento le duplicaría la carga a la pieza más cara. Y el plan B, el selector de categorías, es barato y bueno. Los callers batch (programas que mandan miles de fotos sin una persona esperando) sí reintentan una vez, con espera al azar y con un límite de reintentos, como vas a ver ahora.

Si vas a reintentar, no lo hagas de inmediato. El servidor que acaba de fallar probablemente sigue en el mismo apuro, y un reintento instantáneo le llega justo cuando menos puede.

Duplicar la espera

El backoff exponencial (exponential backoff) es esperar cada vez más entre intentos: la espera se duplica en cada reintento, hasta un tope. Con una base de 100 ms, la espera antes del reintento n es 100 × 2ⁿ ms: 200 ms antes del primero, 400 antes del segundo, 800 antes del tercero. Un tope (por ejemplo, 1 s) evita que la espera crezca sin límite.

¿Por qué duplicar? Porque no sabes cuánto va a durar el problema. Si es un tropiezo de un instante, el primer reintento lo resuelve rápido. Si es largo, la espera crece y los intentos se espacian, en vez de martillar al servidor diez veces por segundo.

El problema de la manada

El backoff tiene un hueco. Imagina que 1,000 clientes fallan en el mismo instante, porque el servidor tuvo un tropiezo de medio segundo. Si todos usan el mismo backoff, todos vuelven a los 200 ms. Juntos. Y los que fallen vuelven a los 600 ms, otra vez juntos. Esperar no separó a nadie: solo movió la ola.

La cura es el jitter: agregarle azar a la espera. La forma más usada se llama full jitter (de un artículo de Marc Brooker en el blog de arquitectura de AWS, Amazon Web Services, la nube de Amazon, de 2015): en vez de esperar exactamente 100 × 2ⁿ ms, cada cliente espera un tiempo al azar entre 0 y 100 × 2ⁿ ms. Antes del primer reintento, entre 0 y 200 ms; antes del segundo, entre 0 y 400; antes del tercero, entre 0 y 800. En promedio se espera la mitad, y los 1,000 clientes quedan repartidos en el tiempo.

Esta simulación lo muestra. Mil clientes fallan juntos en t = 0. El servidor atiende 50 requests en cada ventana de 10 ms (5,000 por segundo) y rechaza el resto. Cada cliente reintenta hasta 3 veces:

import heapq, random                         # heapq: una fila que siempre saca primero el más chico
from collections import Counter

def simular(jitter, clientes=1000, cupo=50, base=100, reintentos=3):
    rng = random.Random(7)                   # semilla fija: sale igual en cada corrida
    def espera(n):                           # reintento n = 1, 2, 3: tope de 200, 400, 800 ms
        tope = base * 2**n
        return rng.uniform(0, tope) if jitter else tope
    fila = [(espera(1), c, 1) for c in range(clientes)]   # todos fallaron en t = 0
    heapq.heapify(fila)
    llegan = Counter()                       # intentos que llegan en cada ventana de 10 ms
    atendidos = rendidos = 0
    while fila:
        t, c, n = heapq.heappop(fila)        # el siguiente intento en el tiempo
        ventana = int(t // 10)
        llegan[ventana] += 1
        if llegan[ventana] <= cupo:          # el servidor atiende 50 por ventana
            atendidos += 1
        elif n < reintentos:
            heapq.heappush(fila, (t + espera(n + 1), c, n + 1))
        else:
            rendidos += 1
    return atendidos, rendidos, max(llegan.values()), sum(llegan.values())

for jitter in (False, True):
    a, r, pico, total = simular(jitter)
    print(f"{'con' if jitter else 'sin'} jitter: {a} atendidos, {r} se rinden, "
          f"pico de {pico} en 10 ms, {total} intentos")

sin jitter: 150 atendidos, 850 se rinden, pico de 1000 en 10 ms, 2850 intentos
con jitter: 1000 atendidos, 0 se rinden, pico de 61 en 10 ms, 1061 intentos

Sin jitter, los 1,000 llegan en la misma ventana: el servidor atiende 50 y rechaza 950. Los 950 vuelven juntos, se atienden 50, y así. Al final, 850 clientes se rinden después de 2,850 intentos. Con jitter, los mismos 1,000 se reparten en unos 200 ms: el pico baja a 61 por ventana, casi todos entran al primer reintento y nadie se rinde. Mismo servidor, mismos clientes; solo cambió el azar en la espera.

Retry-After: cuando el servidor dice cuánto esperar

A veces el servidor sabe mejor que tú cuánto esperar. Para eso existe Retry-After, un header de la respuesta que dice cuándo volver a intentar. Viene sobre todo con un 503 o un 429, y trae segundos o una fecha:

HTTP/1.1 429 Too Many Requests
Retry-After: 2

Esa respuesta dice «pasaste tu límite; vuelve en 2 segundos». Respetarlo es esperar al menos eso antes de reintentar. Ignorarlo es justo lo que el servidor trata de evitar: que todos vuelvan de inmediato y empeoren la saturación.

Respetarlo no quiere decir esperar a ciegas. Si el Retry-After no cabe en tu deadline, no reintentes: ríndete y usa tu plan B. En C01, en 300 ms no cabe esperar un Retry-After de 1 s, así que el camino de Ana cae al selector. Un caller batch, en cambio, sí puede esperar. El de C10, por ejemplo, ajusta cuántas requests manda a la vez: sube mientras todo sale bien y baja con cada 429 o 503, respetando su Retry-After.

Los reintentos ayudan cuando las fallas son pocas y salteadas. Cuando muchas requests fallan a la vez por falta de capacidad, hacen lo contrario: multiplican la carga justo cuando el sistema tiene menos aire. Eso es una tormenta de reintentos (retry storm), la que ya viste en la lección de probabilidad como una falla que llega junta.

Cada capa multiplica

Lo peor pasa cuando varias capas reintentan, cada una por su cuenta. Piensa en una cadena de cuatro piezas: una app llama a una API, la API a un servicio y el servicio al servidor del modelo. Las tres que llaman a otra (la app, la API y el servicio) reintentan 3 veces cada una. Así, cada llamada se vuelve hasta 4 intentos (1 + 3 reintentos), y los intentos se multiplican al bajar:

Lo traicionero es que nadie en ninguna capa ve el problema completo. Cada una cree que está siendo resiliente, porque reintentar suena a buena idea. Y la tormenta no se apaga sola: aunque la causa original desaparezca, la carga de los reintentos alcanza para mantener saturado al servidor. Cada intento fallido produce más intentos.

El presupuesto de reintentos

La primera defensa es poner pocos reintentos en una sola capa. La segunda es un presupuesto de reintentos (retry budget): un tope a cuántos reintentos puede mandar un cliente, como fracción de sus requests normales. El libro de SRE de Google (Site Reliability Engineering, el libro donde Google cuenta cómo opera sus servicios), en su capítulo sobre sobrecarga, usa dos topes juntos:

• Por request: como mucho 3 intentos. Después de eso, la request falla.
• Por cliente: los reintentos no pueden pasar de ≈ 10 % de las requests. Si ya se gastó el presupuesto, el cliente no reintenta: falla de una vez.

Mira la diferencia con números. El gateway manda 500 requests por segundo y, de pronto, el 20 % falla. Para reintentarlas todas mandaría 100 reintentos por segundo; el presupuesto permite 0.1 × 500 = 50. Si la falla es chica y salteada, 50 alcanzan de sobra. Si es grande, el presupuesto se acaba y la carga extra se queda en 10 %, en vez de multiplicarse.

El 10 % no es una ley: cada herramienta trae su número, y la idea es la misma: si muchas fallan, se deja de reintentar.

¿Y en qué capa se reintenta? El libro de SRE elige la que está justo arriba de la que falla. Esa capa, si se rinde, devuelve hacia arriba un error que dice «estoy sobrecargado, no reintentes» (overloaded; don't retry), para que las capas de arriba no se sumen. En C01 la decisión es todavía más simple: en el camino interactivo no reintenta nadie.

Volvamos al timeout ambiguo. La request de Ana pudo haberse hecho y perdido la respuesta. Si el backend reintenta «publicar», puede haber dos publicaciones de los mismos tenis. Si era un cobro, Ana paga dos veces. La pregunta de fondo es: ¿qué operaciones se pueden repetir sin daño?

Una operación es idempotente si hacerla una vez o muchas deja el mismo resultado. Eso es la idempotencia (idempotency). «Pon el volumen en 20» es idempotente: la tercera vez sigue en 20. «Sube el volumen 2 rayitas» no lo es: cada vez queda más alto. En matemáticas se escribe f(f(x)) = f(x). El valor absoluto cumple: |−5| = 5, y |5| sigue siendo 5.

Los métodos de HTTP prometen algo

En la lección de HTTP viste que cada request lleva un método. El estándar de HTTP le asigna a cada uno una promesa:

La promesa la cumple, o no, el servidor. Lo que cuenta es lo que hace, no el nombre del método. La inferencia de Triton se pide con un POST, y aun así es idempotente: clasificar la misma foto dos veces da la misma categoría y no cambia nada en el mundo. Publicar y cobrar, en cambio, no lo son.

La llave de idempotencia

Para que un POST se pueda repetir sin daño, el cliente le pone una llave de idempotencia (idempotency key): un identificador único que genera una vez por operación, no una vez por intento, y que manda igual en cada reintento. Casi siempre es un UUID: un identificador de 128 bits, casi todos al azar, que en la práctica nunca se repite. Viaja en un header, normalmente Idempotency-Key: es el nombre que usa Stripe, una empresa de pagos en línea, y el que propone la IETF, el grupo que escribe los estándares de internet, en un borrador que en noviembre de 2026 todavía no es estándar.

El servidor guarda cada llave junto con la respuesta que dio. Si le llega una llave que ya vio, no repite la operación: devuelve la misma respuesta de antes. Para el cliente, el reintento se ve exactamente como si el primer intento hubiera funcionado.

import uuid

publicaciones = []        # lo que el servidor guardó
ya_hechas = {}            # llave de idempotencia → la respuesta que ya se dio

def publicar(titulo, llave=None):
    if llave in ya_hechas:                 # esta operación ya se hizo
        return ya_hechas[llave]            # devuelve lo mismo, sin publicar otra vez
    publicaciones.append(titulo)
    respuesta = f"publicación #{len(publicaciones)}"
    if llave:
        ya_hechas[llave] = respuesta
    return respuesta

def cliente(titulo, con_llave):
    llave = str(uuid.uuid4()) if con_llave else None   # una por operación, no por intento
    publicar(titulo, llave)                # se publica, pero la respuesta se pierde en la red
    return publicar(titulo, llave)         # el reintento lleva la misma llave

print("sin llave:", cliente("Tenis naranjas", False), "· guardadas:", publicaciones)
publicaciones.clear()
print("con llave:", cliente("Tenis naranjas", True), "· guardadas:", publicaciones)

sin llave: publicación #2 · guardadas: ['Tenis naranjas', 'Tenis naranjas']
con llave: publicación #1 · guardadas: ['Tenis naranjas']

El UUID cambia en cada corrida, y por eso el programa no lo imprime. Lo que importa es que el reintento lleva la misma llave. Si el cliente generara una nueva en cada intento, el servidor vería dos operaciones distintas y publicaría dos veces: la llave no serviría de nada.

Una advertencia de la Ronda (M03): que algo sea idempotente quiere decir que puedes reintentarlo sin efectos raros, no que te convenga. La inferencia de C01 es idempotente, y aun así no se reintenta en el camino de Ana: el problema ahí no son los duplicados, sino la carga y el tiempo.

Los timeouts y los reintentos sirven para fallas cortas. Pero, ¿qué hacer cuando Triton se cae entero durante minutos? Seguir llamándolo es doblemente malo. El gateway espera el timeout completo en cada request, y Triton recibe carga justo cuando intenta levantarse.

Aquí «caído» quiere decir que no contesta nada: su máquina se colgó y los mensajes no reciben respuesta, así que cada llamada espera su timeout. Si en cambio la máquina sigue viva y solo el programa murió, la conexión se rechaza al instante y el gateway contesta de inmediato un 503 con Retry-After, como pide C01. El breaker sirve sobre todo en el primer caso.

El circuit breaker

Un circuit breaker («interruptor de circuito»; la idea la popularizó Michael Nygard en su libro Release It!, de 2007) es un contador dentro del cliente (en C01 sería una biblioteca dentro del gateway, no un servicio aparte) que vigila las fallas de una dependencia. Si son demasiadas, deja de llamarla un rato y contesta de inmediato con el plan B. Tiene tres estados. Los números son los del ejemplo de M15, un punto de partida y no una receta:

• Cerrado (closed): todo normal. Deja pasar las llamadas y cuenta las fallas y los timeouts. Si en los últimos 10 s fallan más del 50 %, con al menos 20 llamadas, se abre.
• Abierto (open): no llama. Cada request recibe el plan B al instante, sin tocar la red. Así se queda 30 s.
• Semiabierto (half-open): deja pasar unas pocas llamadas de prueba, 5. Si salen bien, se cierra; si fallan, vuelve a abrirse otros 30 s.

El mínimo de 20 llamadas existe para la madrugada: sin él, 2 fallas de 3 requests a las 4 a. m. serían «67 % de fallas» y abrirían el breaker por nada.

C01 no trae breaker en su versión de referencia: lo cubren el timeout y el health check del gateway, que lo saca del balanceador cuando Triton cae. La Ronda lo marca como la mejora natural.

Load shedding: rechazar rápido

Cuando llega más de lo que se puede atender, algo tiene que ceder. Lo peor es encolar sin límite: la fila crece, la espera crece con ella y, al final, cada request vence su deadline adentro de la fila. El load shedding («soltar carga») es lo contrario: rechazar de inmediato lo que no vas a poder atender a tiempo, con un 503. Rechazar al entrar cuesta microsegundos; atender una request que ya no llega a tiempo cuesta todo su trabajo, para nada.

C01 lo hace en dos lugares. El gateway, con MAX_INFLIGHT = 16 por pod: la request 17 recibe un 503 al instante. Y la fila de Triton, que rechaza lo que esperó más de 100 ms. Es una forma de backpressure, avisar hacia atrás que no das abasto, con una fila con tope. Y cuando hay que soltar, se suelta primero lo que no tiene a una persona esperando: los callers batch antes que la app de Ana.

Degradación: dar menos, pero dar algo

La degradación (graceful degradation, degradarse con gracia) es responder con algo más simple cuando la pieza buena falla, en vez de un error. En C01, sin sugerencia, Ana elige la categoría a mano en el selector: el fallback de la lección del camino completo. Publicar sigue funcionando, con un paso más.

Un buen plan B tiene dos condiciones: es más barato que el camino normal y no depende de lo que falló. Y se mide: C01 cuenta cada respuesta de plan B por motivo (timeout, 503, foto inválida). Un fallback que se usa en silencio esconde una caída; con su métrica y su alerta, se nota.

¿Abierto o cerrado?

Hay piezas que no dan una respuesta, sino un permiso: un revisor de contenido, un limitador de requests. Si el revisor falla, hay que haber decidido antes qué pasa. Fallar abierto (fail-open) es dejar pasar; fallar cerrado (fail-closed), bloquear. Se elige según qué cuesta más: dejar pasar algo malo un rato, o detener todo lo bueno.

En C06, la moderación de un sitio de publicaciones, si los modelos no contestan a tiempo, el post se publica y se revisa después: bloquear toda publicación porque una GPU tarda sería una caída del producto. En un pago o en un inicio de sesión se elige lo contrario: si no se puede verificar, no pasa.

Ojo con las palabras: en fail-open, «abierto» deja pasar; en el breaker, «abierto» no deja pasar. Una es una puerta; el otro, un circuito eléctrico.

1. Una llamada sin timeout, o un timeout de adentro más largo que el de afuera

Una llamada sin límite, o un gateway que le da 5 s a Triton cuando el caller se va a los 300 ms. Las requests se apilan para respuestas que nadie lee, y un servicio lento se vuelve uno caído.

Cómo evitarlo: un timeout explícito en cada llamada que sale, y cada salto con min(su tope, lo que queda del deadline). Revisa la cadena completa: cada número más chico que el de arriba.

2. Reintentar en todas las capas

Cada capa agrega «sus» 3 reintentos, y tres capas dan 64 intentos por request. Nadie lo ve, porque cada capa por separado se ve razonable.

Cómo evitarlo: reintentos en una sola capa, con presupuesto (≈ 10 %), y que esa capa pase hacia arriba un error de «no reintentes». Dibuja la cadena de llamadas y cuenta los intentos al fondo.

3. Reintentar sin esperar, o esperar todos lo mismo

Un reintento instantáneo le pega al servidor en el mismo apuro. Un backoff sin jitter mueve la ola en vez de repartirla: mil clientes vuelven en el mismo milisegundo.

Cómo evitarlo: backoff exponencial con tope y full jitter, y respetar Retry-After cuando viene.

4. Reintentar lo que no se puede repetir

Un POST de publicar o de cobrar que se reintenta después de un timeout: el primer intento sí se hizo y solo se perdió la respuesta. Ana paga dos veces.

Cómo evitarlo: reintentar solo lo idempotente, o con una llave de idempotencia generada una vez por operación y repetida en cada intento.

5. Reintentar errores permanentes

Un 400 o un 422 se reintenta tres veces y falla tres veces. Peor: un trabajo que falla siempre, como una foto corrupta, se reintenta sin fin y ocupa workers.

Cómo evitarlo: clasificar la falla antes de reintentar: conexión rechazada, 503 y 429 sí; los demás 4xx, no. Ponerle un tope a los intentos de cada trabajo y apartar los que lo pasan.

6. Un plan B que nadie ve, o que nunca se probó

El fallback funciona tan bien que nadie nota que la mitad de las requests lo usa desde hace una semana. O el día que hace falta, descubres que dependía de lo mismo que falló.

Cómo evitarlo: contar cada fallback por motivo, con alerta, y ejercitarlo a propósito de vez en cuando.

Resuélvelos con lápiz antes de abrir la solución. Los de backoff y de amplificación se pueden comprobar con las calculadoras.

1. 1Fácil

   Para cada caso, ¿reintentarías? (a) Conexión rechazada. (b) Un 422. (c) Un 429 con Retry-After: 2, desde un job batch. (d) El mismo 429, en el camino de Ana, que se rinde a los 300 ms. (e) Un 413.

   Ver la solución paso a paso

   • (a) Sí, mejor contra otra réplica: no había nadie escuchando y la request nunca llegó.
   • (b) No: los datos están mal y van a estar mal la segunda vez.
   • (c) Sí, después de al menos 2 s, y dentro del presupuesto.
   • (d) No: 2 s no caben en 300 ms. Se rinde y usa el selector.
   • (e) No: la request es demasiado grande y lo seguirá siendo.
2. 2Fácil

   Un backoff exponencial con base de 50 ms y tope de 1 s hace 5 reintentos. ¿Cuál es la espera máxima antes de cada uno? ¿Cuánto espera en total, como máximo y en promedio con full jitter?

   Ver la solución paso a paso

   • Antes del reintento n: 50 × 2ⁿ ms, con tope de 1,000: 100, 200, 400, 800 y 1,000 ms (el quinto daría 1,600, pero el tope lo recorta).
   • Máximo total: 100 + 200 + 400 + 800 + 1,000 = 2,500 ms.
   • Con full jitter, cada espera es al azar entre 0 y su tope: en promedio, la mitad. 1,250 ms.
3. 3Fácil

   ¿Cuáles son idempotentes? (a) GET de las categorías. (b) PUT que fija el precio de la publicación 42 en 900. (c) DELETE de la publicación 42. (d) POST que crea una publicación. (e) POST a Triton para clasificar una foto.

   Ver la solución paso a paso

   • (a) Sí: leer no cambia nada.
   • (b) Sí: la segunda vez el precio ya es 900.
   • (c) Sí: lo borrado sigue borrado, aunque la segunda respuesta diga que no existe.
   • (d) No: cada vez crea otra. Hace falta una llave de idempotencia.
   • (e) Sí, aunque sea un POST: la misma foto da la misma categoría y no cambia nada. Lo que cuenta es el efecto, no el método.
4. 4Fácil

   ¿Cuántos intentos le llegan al fondo, en el peor caso, con (a) 2 capas que reintentan 2 veces y (b) 4 capas que reintentan 1 vez? ¿Cuántos por segundo con las 500 requests de C01?

   Ver la solución paso a paso

   • (a) Cada llamada se vuelve 1 + 2 = 3 intentos: 3² = 9, y 500 × 9 = 4,500 por segundo.
   • (b) 1 + 1 = 2 por capa: 2⁴ = 16, y 500 × 16 = 8,000 por segundo. Un solo reintento por capa parece inofensivo; con 4 capas, multiplica por 16.
5. 5Medio

   El deadline del gateway es de 250 ms y el tope de la llamada a Triton, 150 ms. ¿Qué timeout le toca a la llamada si recibir y preparar la foto tomó (a) 70 ms y (b) 160 ms? En (b), ¿quién se rinde primero, el gateway o la fila de Triton, que rechaza a los 100 ms?

   Ver la solución paso a paso

   • (a) Quedan 250 − 70 = 180 ms: min(150, 180) = 150 ms.
   • (b) Quedan 250 − 160 = 90 ms: min(150, 90) = 90 ms.
   • En (b), el gateway se rinde a los 90 ms, antes que los 100 de la fila. Si la request sigue en la fila, es trabajo zombi, y por eso conviene que el gateway cancele hacia abajo.
6. 6Medio

   Alguien sube el timeout del gateway hacia Triton a 400 ms «para dar margen». Triton se traba con las 500 requests por segundo de C01, repartidas en 5 pods con MAX_INFLIGHT = 16, y el resto del trabajo de cada request sigue tomando ≈ 40 ms. ¿Cuántas requests quedan en vuelo por pod? ¿Qué parte se rechaza con 503? ¿Qué ve el caller?

   Ver la solución paso a paso

   • Por pod llegan 100 por segundo, y cada request dura ahora ≈ 40 + 400 = 440 ms. Little: 100 × 0.44 = 44 en vuelo, pero solo hay 16 lugares.
   • Cada lugar se libera a los 440 ms: el pod despacha 16 ÷ 0.44 ≈ 36 por segundo. Se rechazan ≈ 64 de 100: ≈ 64 %.
   • Las que entran esperan ≈ 440 ms, pero el caller se fue a los 300: su respuesta llega cuando nadie la espera. Con 150 ms, todas tenían su respuesta a tiempo. Subir el timeout no dio margen: lo quitó.
7. 7Medio

   Triton se cae entero a las 12:00:00, a 500 requests por segundo. El breaker se abre con más de 50 % de fallas en los últimos 10 s (con al menos 20 llamadas); antes de la caída todo iba bien. (a) ¿Cuándo se abre, más o menos? (b) ¿Cuántas requests esperaron sus 150 ms antes de eso? (c) ¿Cuántas no tocan a Triton en los 30 s que está abierto? (d) ¿Qué pasa a las 12:00:35, si Triton sigue caído?

   Ver la solución paso a paso

   • (a) Las fallas pasan del 50 % de la ventana cuando la mitad de los últimos 10 s ya es de caída: ≈ 5 s después, a las 12:00:05.
   • (b) 500 × 5 = ≈ 2,500 requests, cada una con su 504 a los ≈ 150 ms.
   • (c) 500 × 30 = 15,000, cada una con su plan B en ≈ 1 ms.
   • (d) A las 12:00:35 pasa a semiabierto y deja pasar 5 llamadas de prueba. Fallan, y se abre otros 30 s.
8. 8Reto

   Un servicio de búsqueda tiene réplicas de un índice. El 3 % de sus lecturas cae en una réplica que se pausa ≈ 800 ms, al azar; su p95 es de 50 ms y una copia tarda ≈ 40 ms. (a) Sin hedging, ¿dónde queda su p99? (b) Con hedging en el p95, ¿qué fracción sigue lenta, cuánto tarda a lo más una rescatada y cuánta carga extra cuesta? (c) Otro equipo propone lo mismo para una GPU de inferencia al 90 % de uso. ¿Qué le dices?

   Ver la solución paso a paso

   • (a) El 3 % lento es más que el 1 % que deja afuera el p99: el p99 cae en una pausa, ≈ 800 ms.
   • (b) Siguen lentas 0.03 × 0.03 = 0.09 %, menos del 1 %. Una rescatada tarda a lo más 50 + 40 = ≈ 90 ms, y ese es el nuevo p99, más o menos. Cuesta ≈ 5 % de carga: las que pasan del p95.
   • (c) Que no. El 5 % extra la sube a ≈ 0.9 × 1.05 ≈ 94.5 % de uso, más cerca de su límite, en la pieza más cara. Y si su lentitud viene de saturación, la copia es igual de lenta: el hedging solo suma carga.
9. 9Reto

   Diseña la herramienta «reembolsar pedido» del agente de C12. El orquestador la llama con un timeout de 5 s y puede reintentar. (a) ¿Quién genera la llave y cuándo? (b) Un reintento llega mientras el primer intento sigue corriendo: ¿qué debe pasar? (c) Llega la misma llave con otro monto: ¿qué respondes? (d) ¿Cuánto tiempo guardas cada llave?

   Ver la solución paso a paso

   • (a) El orquestador, una vez por reembolso decidido, antes del primer intento, y la manda igual en cada reintento. Si generara una por intento, cada reintento sería otro reembolso.
   • (b) El servidor guarda la llave antes de pagar, con estado «en curso», en una base que no acepta la misma llave dos veces. La segunda copia no paga: espera el resultado o recibe un error de conflicto y vuelve a preguntar.
   • (c) Un error: la misma operación no puede traer otro monto. Devolver el resultado viejo escondería un bug del cliente.
   • (d) Lo que puedan durar los reintentos, con margen: horas o días. Stripe, por ejemplo, documenta al menos 24 horas. Guardarla para siempre cuesta espacio y no protege de nada más.

En la Ronda:

• M02 · Patrones de inferencia, en «Entrega, reintentos e idempotencia»: el backoff con jitter, los 4³ = 64 intentos y la llave que el cliente genera una vez por trabajo.
• M03 · Latencia y capacidad, en «Timeouts, reintentos y hedging»: la jerarquía de timeouts, el presupuesto de 10 %, el hedging en el p95 y el load shedding.
• M15 · Seguridad y confiabilidad, en «Degradación»: la cadena 300 → 250 → 150 → 100 ms, el circuit breaker y el plan B de cada caso, del selector de C01 al fail-open de C06.
• Los casos. C01 (sin reintentos interactivos), C05 (reintentos al SAT), C10 (timeouts por fase) y C12 (llaves en las herramientas).

En el Dojo: la estación 6, «Código de serving», escribe el gateway de C01 con su timeout hacia Triton y su MAX_INFLIGHT, y la 11, «La request en vivo», la sigue cuando algo falla. Cuando abran, ahí lo vas a practicar.

En Sensei: la siguiente lección, «Qué tan rápido y cuánto: latencia y throughput», explica por qué la fila se dispara cerca del 100 % de uso: la razón de fondo para rechazar rápido. La lección «Colas y streams: mensajes que esperan» retoma la idempotencia: una cola que entrega cada mensaje al menos una vez obliga a aguantar duplicados.

Estos son los conceptos que presentó esta lección. Cada uno tiene su tarjeta con la definición completa.

Intenta responder en tu cabeza antes de abrir cada respuesta.

1. 1¿Por qué un servicio lento es peor que uno caído?Ver respuesta

   El caído falla rápido y quien llama pasa a su plan B. El lento retiene memoria, conexiones y lugares en vuelo hasta que todo se atasca. El timeout lo convierte en uno que falla rápido.

2. 2¿Qué diferencia hay entre un timeout y un deadline?Ver respuesta

   El timeout es cuánto espera una llamada. El deadline es el momento en que la request entera deja de importar. Cada salto usa min(su tope, lo que queda del deadline), y así nadie espera más que quien lo llamó.

3. 3¿Por qué el backoff exponencial necesita jitter?Ver respuesta

   Porque los clientes que fallaron juntos, con el mismo backoff, vuelven juntos. El azar en la espera los reparte en el tiempo, y el servidor recibe una llovizna en vez de una ola.

4. 4Tres capas reintentan 3 veces cada una. ¿Cuántos intentos le llegan al fondo, y cómo se evita?Ver respuesta

   4³ = 64. Se evita reintentando en una sola capa, con un presupuesto de ≈ 10 % de las requests, y pasando hacia arriba un error de «no reintentes».

5. 5¿Qué hace un circuit breaker abierto, y para qué sirve si no salva ninguna request?Ver respuesta

   Contesta el plan B al instante, sin llamar. Libera al cliente, da el plan B mucho más rápido y deja que la dependencia se recupere sin carga.

6. 6En C01, ¿por qué el camino de Ana no reintenta, si la inferencia es idempotente?Ver respuesta

   Idempotente quiere decir que se puede, no que convenga. El reintento tendría ≈ 80 ms y le duplicaría la carga a un Triton saturado. El selector es mejor respuesta.