Módulo 09Trimestre 3 · Fiabilidad y escala16 puntos del póster

Rendimiento y escalado

Inicia sesión para guardar tu progreso en todos tus dispositivos. Mientras tanto, se guarda en este navegador.

Por qué importa

Dos errores opuestos matan productos: lanzar algo que se cae con 100 usuarios y sobredimensionar para un millón de usuarios que no tienes. Este módulo te enseña a medir primero y después aplicar la solución más barata, en un orden conocido.

Resultados de aprendizaje

  1. Encontrar cuellos de botella con pruebas de carga y profiling en lugar de adivinar.
  2. Aplicar la escalera de escalado en el orden correcto.
  3. Cachear correctamente, incluida la invalidación.
  4. Entender los balanceadores de carga, los reverse proxies y los API gateways.
  5. Conocer los límites de serverless y los cold starts.
  6. Controlar el coste de la nube y de la IA como una métrica de primer nivel.

La escalera de escalado (sube solo cuando lo hayas medido)

  1. Arregla el código: índices, N+1, paginación, tamaño del payload (03 · Fundamentos de datos).
  2. Caché: CDN para lo estático, caché en el edge para lo dinámico público, caché de aplicación para los cálculos costosos.
  3. Pasa el trabajo a asíncrono (08 · Asincronía, eventos y tiempo real).
  4. Escalado vertical (47): una base de datos o un servidor más grande. Barato en tiempo de ingeniería; llega más lejos de lo que la gente cree.
  5. Escalado horizontal de la capa de aplicación sin estado (46) detrás de un balanceador de carga, con autoescalado (45).
  6. Réplicas de lectura (29) para cargas con muchas lecturas (acepta el retraso de replicación).
  7. Particiona (31) las tablas grandes (por ejemplo, por mes para eventos y logs).
  8. Haz sharding (30) solo cuando una única base de datos primaria de verdad no pueda con la carga. La mayoría de las empresas nunca lo necesitan.

Lecciones

9.1 Caché (2, 48, 49, 50)

  • Capas: navegador (Cache-Control), CDN para recursos estáticos (48), caché en el edge de respuestas dinámicas (49), caché de aplicación (Redis), caché de consultas de la base de datos.
  • Patrones: cache-aside (lectura a través de la app), write-through, stale-while-revalidate.
  • Invalidación (50): TTLs (simple, frescura eventual), purga explícita al escribir (purgas por etiquetas), claves versionadas (user:42:v7).
  • Nunca guardes datos privados por usuario en una caché compartida bajo una clave compartida (fuga de datos). Incluye el usuario o el tenant en la clave, o marca Cache-Control: private.
  • Evita las estampidas: agrupación de peticiones (request coalescing), TTLs con jitter, refresco anticipado.
  • Específico de LLM: usa el prompt caching del proveedor para prefijos estáticos largos; cachea los resultados deterministas (embeddings, clasificaciones).

9.2 Componentes de entrada (3, 4, 5)

  • Reverse proxy (4): termina TLS, comprime, hace de buffer para clientes lentos y enruta (Nginx, Caddy, Cloudflare, el edge de la plataforma).
  • Balanceador de carga (3): reparte el tráfico entre instancias usando health checks; L4 (TCP) o L7 (HTTP). Las sticky sessions son una mala señal; mantén los servidores de aplicación sin estado.
  • API gateway (5): autenticación, cuotas, rate limits, enrutamiento y API keys para muchos servicios. Útil cuando ya tienes varios servicios o vendes acceso a tu API.

9.3 La realidad de serverless (89, 90)

  • Límites: tiempo máximo de ejecución, memoria, tamaño del payload, ejecuciones concurrentes y presión sobre las conexiones a la base de datos. Conoce los números de tu plataforma.
  • Cold starts: la primera petición tras un periodo de inactividad es lenta. Mitígalo con bundles más pequeños, runtimes más ligeros (edge) e instancias aprovisionadas o mínimas en las rutas críticas para la latencia.
  • El trabajo de agentes de larga duración no debe ir en una función atada a la petición; usa jobs duraderos.

9.4 Optimización de costes (88)

  • Trata el coste por usuario activo y el coste por tarea de IA como métricas de producto en el dashboard.
  • Las mayores ganancias: instancias del tamaño adecuado, eliminar recursos ociosos, cachear resultados de LLM, enviar las tareas sencillas a modelos más pequeños o baratos, procesar por lotes, reglas de ciclo de vida del almacenamiento y vigilar el tráfico de salida (egress).
  • Límites de gasto estrictos y alertas de anomalías en cada proveedor. Etiqueta los recursos por producto o venture para poder atribuir costes.

9.5 Método de pruebas de carga

Define el escenario (recorrido de usuario realista, tiempo de reflexión, volumen de datos) → sube la carga por fases (smoke, load, stress, soak) → vigila p95/p99, la tasa de errores y la saturación (CPU, memoria, conexiones a la base de datos, profundidad de las colas) → encuentra lo primero que se rompe → corrígelo → repite.

Lab 9: Encuentra el precipicio

  1. Escribe un escenario de k6 para tu recorrido principal; sube la carga hasta que la tasa de errores supere el 1% o el p95 rompa el presupuesto. Registra el "precipicio".
  2. Haz profiling y corrige el principal cuello de botella. Repite dos veces. Grafica la ganancia de capacidad de cada corrección.
  3. Añade CDN + caché en el edge para una página dinámica pública, con invalidación correcta al actualizar.
  4. Construye un dashboard de costes: coste mensual de infraestructura + IA por usuario activo.

Definition of Done

Paquete de prompts de IA

  • "Con esta salida de k6 y estas estadísticas de la base de datos, ordena los cuellos de botella probables y propón la solución más barata para cada uno."
  • "Añade caché a este endpoint. Incluye el diseño de la clave de caché (con el tenant), el TTL, la invalidación al escribir y la protección contra estampidas."