Ciclo de vida de una petición de API: todos sus saltos
El ciclo de vida de una petición de API en un lienzo interactivo: DNS, TCP y TLS, el enrutamiento por el balanceador de carga, el procesamiento en el servidor y el camino de la respuesta.
Una petición de API no es un solo salto: es una cadena —resolución DNS, establecimiento de la conexión, cifrado, enrutamiento, procesamiento y respuesta— y cada etapa pertenece a una capa distinta.
Ciclo de vida de una petición de API: todos sus saltos
El lienzo interactivo de FlowJam de esta explicación: cada carril, cada fila y cada flecha de arriba forma parte de un diagrama real de QueryChart que puedes abrir y editar.
Cómo leer este diagrama
- Lee primero la columna «Antes de la petición»: DNS, TCP y TLS, las tres idas y vueltas que ocurren antes de enviar nada por HTTP.
- Después sigue la petición hasta «Procesamiento en el servidor»: balanceador de carga, handler, base de datos y serialización.
- Lee la columna «Respuesta» como la imagen especular: la respuesta rehace el mismo camino de vuelta hasta el cliente.
Antes de la petición
«El navegador resuelve el dominio por DNS» es la primera ida y vuelta: el dominio se convierte en una dirección IP, que es el tema del diagrama de DNS. «Se establece una conexión TCP» abre la tubería fiable de bytes y «El handshake TLS asegura la conexión» la cifra, que es el tema del diagrama de HTTPS. Solo entonces «Se envía la petición HTTP». Esas tres cajas iniciales son la razón de que una llamada a una API en frío sea visiblemente más lenta que una en caliente.
Procesamiento en el servidor
«El balanceador de carga enruta a un servidor de aplicación» reparte la petición entre las instancias sanas. «El handler valida y procesa la petición» es donde se ejecuta el código de la aplicación —el handler es la función que atiende la ruta—, «El servidor consulta la base de datos» es el salto de datos, normalmente el más lento, y «El servidor serializa la respuesta» es el formateo de vuelta. La separación en carriles mantiene visiblemente separados el borde de la red, la aplicación y el almacén de datos, porque tienen modos de fallo distintos y presupuestos de latencia distintos.
El camino de la respuesta
«La respuesta vuelve por el mismo camino» y «El cliente analiza y renderiza la respuesta» cierran el círculo. La respuesta no vuelve por arte de magia: cruza el mismo balanceador de carga, la misma red y la misma conexión que llevaron la petición. Entender que el camino es compartido es lo que explica por qué los timeouts de petición y los de respuesta son el mismo problema, y por qué las dos columnas se reflejan una en otra.
Relaciones clave y conclusiones
- DNS, TCP y TLS preceden a la petición HTTP: tres idas y vueltas antes de que se ejecute nada de código de aplicación.
- El balanceador de carga hace que muchos servidores parezcan una sola dirección; el cliente nunca ve el servidor real.
- La consulta a la base de datos es el salto más lento de la mayoría de las llamadas a una API, y por eso importan la caché y los índices.
- La respuesta rehace el camino de la petición: las dos direcciones cruzan la misma red y el mismo balanceador de carga.
- El ciclo de vida compone los demás diagramas: DNS, HTTPS y REST son etapas de este mismo viaje.
Cuándo usar este diagrama
- Enseñar a un ingeniero nuevo por qué la latencia de una API es más que el código del servidor: las etapas de red y de establecimiento son reales.
- Depurar la lentitud: el lienzo nombra los saltos que hay que medir: tiempo de DNS, TTFB, tiempo de servidor y tiempo de transferencia.
- Anclar una conversación sobre balanceo de carga y caché en el punto del viaje donde encaja cada uno.
Cómo funciona
Dibuja tu infraestructura real
Sustituye el balanceador de carga, el servidor de aplicación y la base de datos genéricos por tus componentes reales —tu CDN, tus instancias, tu almacén de datos— y mantén una caja por salto.
Anota el presupuesto de latencia
Añade un comentario a cada salto con su tiempo habitual en tu sistema —consulta DNS, conexión, TLS, tiempo de servidor, base de datos— para que el lienzo se convierta en un perfil de latencia.
Añade la capa de caché
Inserta una caja de caché entre el balanceador de carga y el handler, con una rama para el acierto de caché y otra para el fallo, porque esa es la palanca que la mayoría de los equipos mueve primero.
Dibuja las ramas de fallo
Añade los finales de fallo reales —un timeout de DNS, un error de TLS, un 502 del balanceador de carga, una caída de la base de datos— y termina cada uno en un resultado explícito.
Preguntas frecuentes
¿Cuáles son las etapas de una petición de API?
Antes de enviar nada por HTTP, el cliente resuelve el dominio por DNS, abre una conexión TCP y hace un handshake TLS. Después la petición viaja hasta un balanceador de carga, que la enruta a un servidor de aplicación; el servidor la valida y la procesa, consulta la base de datos y serializa una respuesta; y la respuesta vuelve por el mismo camino. Las tres columnas del diagrama son exactamente esos tres grupos de etapas.
¿Por qué es lenta una llamada a una API antes de que el servidor haga nada?
Porque la resolución DNS, la conexión TCP y el handshake TLS son idas y vueltas reales que ocurren antes de enviar un solo byte de HTTP. En una conexión en frío pueden tardar más que el propio procesamiento de la petición. Por eso el diagrama empieza con la columna «Antes de la petición»: la mayor parte de la latencia de una primera petición es el establecimiento, no el código del servidor.
¿Cuál es el papel del balanceador de carga en el ciclo de vida de la petición?
El balanceador de carga es la puerta de entrada estable detrás de la cual viven los servidores reales. Acepta la petición, elige una instancia sana y reenvía el tráfico, y también suele ser donde terminan las comprobaciones de salud y el TLS. Los clientes nunca saben qué servidor los atendió, y eso es lo que permite añadir y quitar servidores sin cambiar el cliente.
¿Por qué vuelve la respuesta por el mismo camino?
Porque la conexión es el camino: la respuesta viaja por la misma conexión TCP/TLS, por la misma red y por el mismo balanceador de carga que llevaron la petición. La simetría importa en la operación —un salto lento o roto afecta a las dos direcciones—, y por eso el diagrama dibuja la columna de la respuesta como el reflejo de la de la petición, en lugar de dar por gratis el viaje de vuelta.
Edita este diagrama en QueryChart (FlowJam)
Abre este mismo lienzo del ciclo de vida como tu propio diagrama, renombra los saltos con tu infraestructura y traza tus peticiones reales.