Software Architecture
Explica load balancers, reverse proxies y API gateways, sus responsabilidades de routing, TLS, autenticación, límites, observabilidad y puntos de fallo.
La capa de entrada recibe tráfico, aplica políticas técnicas y dirige solicitudes a destinos capaces de procesarlas. Su objetivo es proteger y distribuir, no convertirse en un segundo dominio lleno de reglas de negocio.
Cuando una aplicación tiene varias instancias o regiones, el cliente necesita una puerta de entrada estable.
cliente
→ DNS / edge
→ load balancer o reverse proxy
→ gateway
→ servicio o instanciaCada capa puede aportar routing, TLS, límites, observabilidad y protección. Sin disciplina, la cadena acumula timeouts, retries y transformaciones que vuelven difícil saber dónde falló una solicitud.
Supón tres instancias de una API.
Sin balanceador, el cliente tendría que conocerlas y detectar cuál está disponible.
Con balanceador:
request
→ seleccionar destino saludable
→ enviar
→ observar resultadoEl balanceador oculta topología y permite reemplazar instancias. Sin embargo, solo funciona bien si puede distinguir capacidad real, evitar destinos degradados y retirar instancias de forma segura.
Opera con conexiones TCP/UDP, IP y puerto.
Ventajas:
Limitaciones:
Comprende HTTP y puede decidir por:
Permite canary releases, routing por versión y políticas más expresivas. A cambio añade parsing, configuración y superficie de seguridad.
Un reverse proxy representa a servidores internos frente al cliente.
Puede:
Debe preservar información confiable como IP, protocolo y trace context sin aceptar headers falsificados desde clientes no confiables.
Un gateway centraliza políticas comunes de APIs:
La autorización de negocio permanece cerca del dominio.
Ejemplo:
gateway verifica que el token sea válido
→ Orders verifica que el actor puede confirmar ese pedido del tenantEl gateway no debería decidir reglas como “un cajero solo puede cancelar pedidos antes de preparación”, porque ese conocimiento pertenece al contexto.
Alterna destinos.
Funciona cuando capacidad y duración son similares.
Problema: una instancia lenta recibe la misma cantidad que una rápida.
Asigna más tráfico a destinos con mayor capacidad.
Útil para:
Los pesos estáticos pueden quedar obsoletos durante degradación.
Prefiere el destino con menos conexiones activas.
Ayuda cuando las solicitudes tienen duraciones variables.
No siempre representa carga real: una conexión puede estar ociosa y otra consumir CPU intensa.
Cuenta requests en vuelo. Es más útil para HTTP que conexiones persistentes.
Usa una clave para mantener afinidad aproximada.
Casos:
Riesgo: una clave caliente concentra tráfico.
Favorece destinos con menor latencia observada.
Puede reaccionar a degradación, pero necesita suavizado para no producir oscilación.
Un algoritmo no compensa una instancia saturada si sigue marcada como saludable.
Señales posibles:
Los mecanismos adaptativos deben evitar flapping: mover tráfico demasiado rápido puede sobrecargar la siguiente instancia.
Un único endpoint /health suele mezclar conceptos distintos.
Indica si la inicialización terminó.
Mientras falla, el proceso no debería recibir tráfico ni ser reiniciado por lentitud normal de arranque.
Indica si el proceso puede progresar.
Debe detectar deadlock o estado irrecuperable local.
No debería fallar solo porque una dependencia externa está caída; reiniciar todas las instancias no corrige PostgreSQL o un proveedor.
Indica si puede aceptar tráfico ahora.
Puede fallar cuando:
Verifica dependencias con mayor profundidad para diagnóstico, no necesariamente para routing cada pocos segundos.
Si readiness consulta todas las dependencias y una falla, el balanceador puede retirar todas las instancias.
Payments caído
→ todas las APIs no ready
→ también se pierde catálogo y perfilLa readiness debe representar capacidad de atender el tráfico asignado y considerar degradación parcial.
Antes de terminar una instancia:
Sin draining, despliegues y autoscaling cortan operaciones en vuelo.
Reutilizar conexiones evita handshake y TLS repetidos.
Pero pools mal dimensionados producen:
El balanceo por conexión puede ser desigual con HTTP/2 o conexiones largas porque muchas solicitudes viajan por una sola conexión.
Cada capa puede tener:
Deben alinearse.
cliente: 3 s
gateway: 2,5 s
servicio: 2 s
downstream: 1 sSi el proxy espera 60 s y el cliente abandona a 3 s, el backend continúa trabajo inútil. Propaga cancelación cuando sea posible.
Un proxy puede reintentar cuando el destino falla antes de procesar.
Es seguro normalmente para:
Es peligroso cuando:
cliente: 3 intentos
gateway: 3 intentos
servicio: 3 intentos
→ hasta 27 llamadas downstreamDurante degradación, esto produce tormenta de carga.
Define una capa responsable y un retry budget.
Controla cuántas operaciones acepta el sistema.
Dimensiones posibles:
Limitar solo IP es insuficiente detrás de NAT o para usuarios autenticados.
Acumula tokens hasta una capacidad y permite bursts.
Suaviza salida a una tasa constante.
Simple, pero permite ráfagas en límites de ventana.
Más preciso, con mayor costo.
La respuesta debe incluir límites y, cuando aplique, Retry-After.
Rate limiting protege velocidad inmediata. Cuotas controlan consumo acumulado:
En multi-tenancy, combina límite global con límite por tenant para evitar noisy neighbors.
Cuando la capacidad se agota, rechazar temprano puede preservar el sistema.
prioridad alta: pagos, pedidos
prioridad baja: reportes, recomendacionesEl gateway puede rechazar endpoints costosos, pero la prioridad de negocio debe definirse con los dominios.
Un gateway puede dejar de enviar tráfico a un upstream degradado.
Debe distinguir:
Un circuito global mal configurado puede bloquear un servicio por errores de una región.
Topología típica:
DNS / global traffic manager
├── región A
│ └── balanceador regional → zonas → instancias
└── región B
└── balanceador regional → zonas → instanciasLa capa global decide por:
La capa regional distribuye dentro de zonas e instancias.
Preguntas necesarias:
Dirigir tráfico sin garantizar datos y capacidad solo mueve el fallo.
Se envía una pequeña proporción a la nueva versión.
v1: 95 %
v2: 5 %Observa:
El canary debe representar usuarios reales; enviar solo health checks no valida comportamiento.
Dos entornos completos permiten cambiar routing.
Beneficios:
Costos:
El rollback de aplicación no deshace datos escritos por la nueva versión.
Sticky sessions mantienen un cliente en la misma instancia.
Puede simplificar estado local, pero introduce:
Alternativas:
No la elimines por dogma si WebSocket u otro flujo necesita conexión persistente; diseña recuperación.
Las conexiones largas cambian el balanceo:
Termina en un límite confiable. Si el tráfico interno cruza redes no confiables, considera TLS o mTLS adicional.
El proxy debe eliminar o reemplazar headers como X-Forwarded-For provenientes de clientes.
Configuraciones inconsistentes entre proxies sobre longitud y transferencia pueden permitir interpretar una request de formas distintas.
Mantén parsers y normalización consistentes.
Limita:
Protege contra consumo de recursos.
Puede bloquear patrones conocidos, pero no reemplaza validación, autorización ni código seguro.
Métricas de entrada:
Propaga:
No registres secretos, tokens ni bodies sensibles.
Internet
→ CDN/WAF
→ load balancer
→ gateway
→ monolito modular
→ PostgreSQL / RedisSi la nueva versión necesita un schema incompatible, el proceso falla aunque el balanceo sea perfecto. Usa expand-and-contract.
Liveness pasa, readiness quizá también. Usa señales adaptativas, límites y queue depth.
Una dependencia intermitente alterna estado y el balanceador mueve tráfico constantemente. Usa hysteresis y umbrales.
El gateway reintenta un POST y duplica pedido. Exige idempotency key o no reintentar.
El servicio desaparece aunque podría degradarse. Rediseña readiness.
No detecta errores raros. Define duración, volumen y métricas de negocio.
Clientes siguen región antigua. Usa TTL adecuado, anycast o mecanismos complementarios.
Decide fail-open o fail-closed según riesgo. Un endpoint público y una API de pagos pueden elegir distinto.
Centraliza acoplamiento y obliga a desplegarlo por cada cambio. Mantén políticas técnicas en entrada.
Convierte fallos externos en reinicios y retirada masiva.
Envía tráfico a procesos sin capacidad real.
Capas superiores abandonan antes o inferiores cortan operaciones válidas.
Amplifican tráfico y duplican efectos.
Ocultan estado local y dificultan failover.
Castiga usuarios detrás de NAT y no controla tenants autenticados.
Corta requests, mensajes y streams durante deploy.
Conviene cuando existen múltiples APIs, políticas comunes, clientes externos o necesidad de routing central.
Puede ser innecesario para una aplicación pequeña con un único backend y plataforma gestionada que ya cubre TLS y routing.
No añadas una capa solo para tener un nombre arquitectónico.
Patrones de resiliencia utiliza timeouts, límites, circuit breakers, bulkheads y degradación para contener fallos después de que el tráfico entra al sistema.