Redes para ingenieros de backend

Los sistemas backend están diseñados para recibir solicitudes, ejecutar lógica y devolver respuestas. En la práctica, esas solicitudes suelen originarse en otras máquinas, no en la misma computadora donde se ejecuta el backend.

Cuando un usuario interactúa con una aplicación web o móvil, su dispositivo envía una solicitud a través de internet a un servidor remoto. Esa solicitud viaja por varios componentes de red antes de llegar a la aplicación backend.

Los sistemas backend también se comunican internamente. Un servicio puede llamar a otro servicio, consultar un servidor de base de datos o enviar solicitudes a APIs externas. Todas estas interacciones ocurren a través de una red.

Debido a esto, muchos problemas del sistema se originan en el comportamiento de la red y no en el código de la aplicación. Las llamadas lentas a la API pueden deberse a la latencia de red, las conexiones interrumpidas pueden cortar solicitudes y los reintentos suelen ocurrir cuando las respuestas no llegan a tiempo.

Entender cómo se comunican las máquinas a través de redes ayuda a los ingenieros a razonar sobre el rendimiento, la confiabilidad y los escenarios de fallo en sistemas distribuidos.

Cuando una aplicación cliente envía una solicitud a un sistema backend, ocurren varios pasos de red antes de que el código del backend siquiera comience a ejecutarse.

El proceso normalmente comienza con un nombre de dominio como api.example.com. Las computadoras no pueden comunicarse directamente usando nombres de dominio, así que el cliente primero realiza una consulta DNS para determinar la dirección IP del servidor de destino.

Una vez que se conoce la dirección IP, el cliente establece una conexión TCP con esa máquina. Esta conexión crea un canal confiable para enviar datos entre el cliente y el servidor.

Después de establecer la conexión, el cliente envía una solicitud HTTP. Esta solicitud contiene el método, los encabezados y cualquier dato que necesite el sistema backend.

En las arquitecturas modernas, la solicitud a menudo pasa por un balanceador de carga antes de llegar al servidor de la aplicación. El balanceador de carga decide qué máquina backend debe manejar la solicitud, ayudando a distribuir el tráfico entre varios servidores.

Finalmente, la solicitud llega al servidor de la aplicación, donde la aplicación backend la procesa, ejecuta la lógica de negocio y genera una respuesta que vuelve al cliente.

Las computadoras se comunican entre sí usando direcciones IP numéricas como 142.250.72.14. Sin embargo, las personas interactúan con los servicios a través de nombres de dominio como api.example.com porque son más fáciles de recordar.

El Sistema de Nombres de Dominio (DNS) actúa como un directorio distribuido que asigna estos nombres de dominio a sus direcciones IP correspondientes. Cuando un cliente quiere contactar a un servidor usando un nombre de dominio, envía una consulta DNS para determinar la dirección IP correcta.

Este proceso de búsqueda puede involucrar varios servidores DNS trabajando juntos. Finalmente, el sistema devuelve la dirección IP asociada con el dominio solicitado para que el cliente sepa a dónde enviar la solicitud.

Para mejorar la eficiencia, las respuestas DNS suelen almacenarse en caché por los sistemas operativos, los navegadores y los servidores intermedios. Si ya existe una búsqueda reciente en la caché, el sistema puede reutilizar la dirección IP almacenada en lugar de realizar una nueva consulta DNS.

DNS es un componente fundamental de la infraestructura de Internet. Sin él, los usuarios y las aplicaciones tendrían que recordar y gestionar manualmente direcciones IP numéricas para cada servicio con el que interactúan.

Una vez que un cliente conoce la dirección IP de un servidor, todavía necesita determinar qué aplicación en ese servidor debe manejar la solicitud. Aquí es donde se usan los puertos.

Un puerto es un punto final de comunicación lógico en una máquina. Mientras que la dirección IP identifica al host en sí, el puerto identifica el servicio específico que escucha las conexiones entrantes.

Por ejemplo, un servidor web normalmente escucha en el puerto 80 para tráfico HTTP o en el puerto 443 para tráfico HTTPS. Las bases de datos y otros servicios también usan puertos conocidos. PostgreSQL suele escuchar en el puerto 5432, mientras que Redis a menudo se ejecuta en el puerto 6379.

Como los puertos separan los servicios, una sola máquina puede ejecutar muchas aplicaciones diferentes al mismo tiempo. Un servidor backend podría alojar una API HTTP, una base de datos y un servicio de caché al mismo tiempo, cada uno vinculado a un puerto diferente.

Juntos, la combinación de una dirección IP y un número de puerto define un punto final de red. Este punto final identifica de forma única dónde debe entregarse una solicitud.

Transmission Control Protocol (TCP) es uno de los protocolos de comunicación principales utilizados en internet. Está diseñado para proporcionar una comunicación fiable entre dos máquinas.

Antes de transmitir cualquier dato, TCP establece una conexión mediante un proceso llamado three-way handshake. El cliente comienza enviando un mensaje SYN al servidor. El servidor responde con SYN-ACK para confirmar la solicitud e indicar que está listo. Luego, el cliente envía un mensaje ACK confirmando la conexión. Después de este intercambio, ambas máquinas pueden comenzar a enviar datos.

TCP divide los datos en unidades más pequeñas llamadas paquetes y los transmite a través de la red. Como las redes pueden perder o reordenar paquetes, TCP incluye mecanismos que detectan datos faltantes y retransmiten paquetes si es necesario.

Otra característica importante de TCP es el orden de los paquetes. Incluso si los paquetes llegan en un orden distinto al que fueron enviados, TCP los reensambla correctamente antes de entregar los datos a la aplicación.

Estos mecanismos hacen que TCP sea fiable para aplicaciones que requieren una transferencia de datos precisa, como solicitudes web, comunicación con bases de datos y la mayoría de las interacciones con API.

TCP y UDP son dos protocolos de transporte principales usados para la comunicación entre máquinas, pero resuelven problemas diferentes.

TCP (Transmission Control Protocol) está diseñado para la fiabilidad. Establece una conexión entre dos máquinas, garantiza que los paquetes lleguen correctamente, retransmite los datos perdidos y asegura que los paquetes se entreguen en el orden correcto. Debido a estas garantías, TCP se usa en aplicaciones donde la precisión es crítica.

Muchos sistemas backend dependen de TCP. Protocolos web como HTTP funcionan sobre TCP, y las conexiones a bases de datos también suelen usar TCP porque la integridad de los datos es esencial.

UDP (User Datagram Protocol) adopta un enfoque diferente. No establece una conexión y no garantiza la entrega ni el orden. En su lugar, simplemente envía los paquetes al destino lo más rápido posible.

Como UDP elimina la sobrecarga de fiabilidad, es más rápido y ligero. Esto lo hace adecuado para aplicaciones donde una pérdida ocasional de paquetes es aceptable, como la transmisión de video en tiempo real, los juegos en línea y muchas consultas DNS.

La compensación entre TCP y UDP se basa fundamentalmente en fiabilidad frente a velocidad. Los sistemas eligen el protocolo que mejor se adapta a las necesidades de la aplicación.

HTTP (Hypertext Transfer Protocol) es el protocolo de la capa de aplicación que usan la mayoría de los sistemas web. Define la estructura de los mensajes intercambiados entre clientes y servidores.

La comunicación sigue un modelo de solicitud–respuesta. Un cliente envía una solicitud HTTP describiendo lo que quiere hacer, y el servidor procesa esa solicitud y devuelve una respuesta HTTP.

Las solicitudes incluyen varios componentes. El método HTTP indica la acción prevista, como GET para recuperar datos o POST para enviar datos nuevos. La solicitud también incluye encabezados que transportan metadatos como tokens de autenticación, tipo de contenido o instrucciones de caché.

Después de procesar la solicitud, el servidor devuelve una respuesta. La respuesta incluye un código de estado que indica el resultado de la operación. Por ejemplo, 200 OK indica éxito, mientras que códigos como 404 o 500 señalan errores.

HTTP proporciona el lenguaje estandarizado que permite que navegadores, aplicaciones móviles y servicios de backend se comuniquen de forma consistente a través de internet.

La latencia se refiere al tiempo que tarda una solicitud en viajar desde un cliente hasta un servidor y en que la respuesta regrese. En los sistemas distribuidos, incluso las operaciones simples implican varios pasos que contribuyen a este retraso.

Primero, la solicitud debe viajar a través de la red. Los datos se mueven por routers, switches y, a veces, por varios centros de datos antes de llegar al servidor de destino. La distancia geográfica por sí sola puede introducir retrasos notables porque las señales tardan en propagarse a largas distancias.

Una vez que la solicitud llega al servidor, el sistema backend debe procesarla. Esto puede implicar ejecutar la lógica de la aplicación, realizar validaciones o ejecutar otras operaciones internas.

Muchas solicitudes también dependen de otros sistemas, como bases de datos, cachés o APIs externas. Cada dependencia adicional introduce su propio tiempo de procesamiento y latencia de red.

Otros factores, como la congestión de la red o servicios sobrecargados, pueden aumentar aún más la latencia. Debido a que los sistemas distribuidos dependen de muchos componentes interconectados, pequeños retrasos en varios lugares pueden acumularse hasta convertirse en tiempos de respuesta perceptibles.

La comunicación de red es inherentemente poco fiable. Las solicitudes pueden retrasarse, las conexiones pueden caerse y los servicios pueden dejar de responder. Por eso, los sistemas backend deben diseñarse para manejar de forma segura las llamadas de red lentas o fallidas.

Una protección común es un tiempo de espera. Un tiempo de espera define la cantidad máxima de tiempo que un sistema esperará una respuesta. Si la respuesta no llega dentro de esa ventana, la solicitud se aborta y el sistema sigue adelante.

Los reintentos son otra estrategia común. Cuando una solicitud falla debido a un problema temporal de red, el sistema puede intentar la solicitud de nuevo después de un breve retraso. Esto puede ayudar a recuperarse de fallos transitorios, como interrupciones breves de la red.

Sin embargo, los reintentos deben controlarse cuidadosamente. Si muchos servicios reintentan repetidamente solicitudes fallidas, pueden sobrecargar los sistemas aguas abajo y crear fallos en cascada, donde un servicio lento provoca interrupciones generalizadas.

Por esta razón, los sistemas backend modernos configuran cuidadosamente los tiempos de espera, los reintentos y las estrategias de manejo de fallos para mantener la fiabilidad incluso cuando partes de la red se comportan de forma impredecible.

A medida que las aplicaciones crecen, un solo servidor a menudo no puede manejar todo el tráfico entrante. Para dar soporte a más usuarios y mantener el rendimiento, los sistemas ejecutan varios servidores backend que ofrecen la misma funcionalidad.

Un balanceador de carga actúa como punto de entrada para las solicitudes entrantes. En lugar de que los clientes se conecten directamente a servidores individuales, envían las solicitudes al balanceador de carga. Luego, el balanceador de carga decide qué servidor backend debe manejar cada solicitud.

Esta distribución reparte el tráfico entre los servidores, evitando que una sola máquina se sobrecargue. Se pueden usar distintos algoritmos, como distribución round-robin, enrutamiento por menor número de conexiones o enrutamiento basado en latencia.

El balanceo de carga también mejora la tolerancia a fallos. Si un servidor deja de estar disponible, el balanceador de carga puede dirigir el tráfico a otros servidores sanos para que el sistema siga funcionando.

Este enfoque permite el escalado horizontal, donde los sistemas aumentan su capacidad añadiendo más máquinas en lugar de actualizar un solo servidor. El escalado horizontal es una estrategia fundamental para construir sistemas backend grandes y confiables.