Nodos, aristas y direcciones
Una solicitud como un recorrido en un grafo
Cada componente al que toca una solicitud es un nodo: cliente, resolutor DNS, borde de CDN, proxy inverso, réplica de backend, base de datos, caché.
Cada conexión entre dos nodos es una arista dirigida: las solicitudes fluyen hacia adelante y las respuestas fluyen hacia atrás. La arista hacia adelante representa una conexión TCP abierta más el protocolo que se ejecuta sobre ella.
Una sola solicitud es un camino a través de este grafo. El trabajo total que realiza el sistema para responder a la solicitud es igual a la suma del trabajo en cada nodo, más la latencia de cada arista.
¿Por qué importa? Una vez que dibujas el grafo, surgen propiedades que son invisibles en el código:
- Número de saltos (hop count): el número de aristas en la ruta. Cada salto añade latencia (ida y vuelta de red + procesamiento del nodo). Menos saltos = menor límite inferior de latencia.
- Grado de entrada (in-degree): cuántas aristas apuntan HACIA un nodo. Un alto grado de entrada significa que el nodo recibe solicitudes de muchas fuentes y debe escalar o protegerse.
- Grado de salida (out-degree): cuántas aristas salen DE un nodo. Un alto grado de salida significa que el nodo depende de muchos componentes aguas abajo y tiene muchas formas de fallar.
- Vértice de corte (cut vertex): un único nodo cuya eliminación desconecta el grafo. Un proxy inverso sin un par (peer) es un vértice de corte; eliminarlo elimina todo el acceso a sus orígenes.
Dónde se concentra el tráfico
Abanico de entrada = Concentración
El grado de entrada de un nodo = número de aristas que apuntan hacia él. En un grafo de solicitudes, el grado de entrada = número de fuentes aguas arriba que envían solicitudes.
Patrón de convergencia (fan-in): muchos clientes -> un CDN; muchos bordes del CDN -> pocos proxies de origen; muchos proxies -> menos réplicas de backend; muchos backends -> una sola base de datos.
La concentración es importante porque el nodo con el mayor grado de entrada ve la mayor carga agregada. La base de datos al final de la cadena puede ver consultas de cada solicitud activa en todo el sistema, incluso si ningún usuario individual genera mucha carga.
Fan-Out = Dependencia
El grado de salida de un nodo = número de aristas que salen de él. Un alto grado de salida significa muchas dependencias aguas abajo.
Un backend que llama a una base de datos, dos cachés, tres APIs externas y una cola tiene un grado de salida de 7. Su probabilidad de éxito es aproximadamente el producto de la probabilidad de éxito de cada dependencia aguas abajo (si todas son necesarias para una respuesta exitosa).
0.999 ^ 7 ≈ 0.993: un backend con 7 dependencias aguas abajo, cada una con una fiabilidad del 99.9%, solo puede lograr una fiabilidad de ~99.3% por sí mismo, incluso sin tener ningún bug propio.
Reducir el grado de salida mediante: caché de resultados aguas abajo, hacer que las dependencias no críticas sean opcionales (degradación elegante), paralelizar lo que se pueda paralelizar.
La Asimetría
El fan-in concentra la carga; el fan-out multiplica el riesgo. Un grafo bien diseñado minimiza ambos en los nodos de mayor impacto.
La base de datos (mayor fan-in): usar caché de forma agresiva para reducir la carga. Réplicas de lectura para distribuir el fan-in entre múltiples nodos.
El servicio orquestador (mayor fan-out): circuit breakers por dependencia, degradación elegante, bulkheads.
Un nodo insertado compra flexibilidad
Indirección = Añadir un nodo intermedio
Sin un proxy, el grafo es: client -> backend. El cliente debe conocer la dirección del backend. Mover el backend requiere actualizar el cliente (vía DNS o configuración). Este es un acoplamiento fuerte.
Con un proxy, el grafo se convierte en: client -> proxy -> backend. El cliente solo conoce el proxy. Mover el backend requiere actualizar la configuración upstream del proxy, no el cliente.
La operación en el grafo: insertar un nodo a lo largo de una arista existente. La nueva arista client -> proxy es estable; la nueva arista proxy -> backend ahora es responsabilidad del equipo de gestión.
Lectura geométrica: la indirección añade una capa que desacopla el cambio upstream del cambio downstream. Las aristas de cada capa pueden reconfigurarse de forma independiente.
Costo de la Indirección
Cada capa añade:
- Un salto de latencia (el borde del cliente al proxy)
- Un punto de corte más en el camino (el propio proxy)
- Un lugar más donde puede ocurrir una mala configuración
Los beneficios (reconfigurar, escalar, proteger, terminar TLS, distribuir la carga) suelen superar los costos en cualquier sistema no trivial. Pero hay un límite: cada capa de indirección añade otro salto y otro candidato a punto único de fallo (SPOF).
La regla folclórica: cualquier problema puede resolverse añadiendo una capa de indirección (excepto el problema de tener demasiadas capas de indirección).
Leer una arquitectura como un grafo
Síntesis
Ahora puedes leer una arquitectura de sistema como un grafo: contar saltos, identificar vértices de corte, medir la concentración de fan-in, calcular los límites de disponibilidad a partir del fan-out y evaluar las compensaciones de la indirección.
Aplica los cuatro.
Un nuevo servicio tiene esta arquitectura: clients -> CDN -> reverse proxy (2 replicas) -> backend tier (8 replicas) -> { DB primary, cache cluster (3 nodes), external API }.
Notas complementarias
Notas complementarias
Esta lección de geometría reformula la lección principal de Proxies & Origins como un análisis de grafos dirigidos.
La siguiente lección complementaria de este curso, geometry_of_stateless_horizontal_scaling, toma la matemática de réplicas de la lección principal de escalado y deriva geométricamente la curva de colas, la Ley de Little y la rodilla de utilización del 80 %.
Buen trabajo.