Week 22 — AI Engineering at Scale

1. Objetivos de Week 22

WEEK 20

¿Es segura?


        ↓


WEEK 21

¿Es un buen producto?


        ↓


WEEK 22

¿Puede soportar crecimiento?


        ↓


WEEK 23

¿Podemos operarla?


        ↓


WEEK 24

¿Podemos convertirnos
en AI Application Engineers?

Al finalizar esta semana deberás ser capaz de:

• explicar qué significa escalar;
• distinguir scaling vertical y horizontal;
• entender una arquitectura distribuida;
• diseñar aplicaciones stateless;
• entender load balancing;
• utilizar caching;
• entender Redis;
• optimizar PostgreSQL;
• utilizar connection pooling;
• diseñar background jobs;
• utilizar queues;
• crear workers;
• diseñar arquitecturas event-driven;
• crear un AI Gateway;
• hacer model routing;
• controlar rate limits;
• gestionar operaciones asíncronas;
• diseñar sistemas resilientes;
• implementar observabilidad;
• controlar costes de IA;
• diseñar backups y disaster recovery;
• hacer load testing;
• razonar sobre arquitecturas para 100, 10.000, 100.000 y 1.000.000 usuarios.

2. ¿Qué significa escalar?

Escalar significa conseguir que un sistema pueda soportar un aumento de carga sin degradarse de manera inaceptable.

¿Qué es carga?

Puede ser:

• usuarios simultáneos;
• requests por segundo;
• consultas a base de datos;
• documentos procesados;
• imágenes analizadas;
• tokens enviados a modelos;
• jobs pendientes;
• eventos generados.

Ejemplo

100 usuarios
×
5 acciones / minuto

=

500 acciones / minuto


Ahora:

10.000 usuarios
×
5 acciones / minuto

=

50.000 acciones / minuto

El problema no es solamente que haya más usuarios. También aparecen nuevos cuellos de botella.

3. Vertical vs Horizontal Scaling

Vertical Scaling

Hacemos más potente una máquina.

ANTES

4 CPU
8 GB RAM


        ↓


DESPUÉS

16 CPU
64 GB RAM

Es sencillo, pero tiene límites.

Horizontal Scaling

Añadimos más máquinas.

             USERS
                │
                ▼
        ┌──────────────┐
        │ LOAD BALANCER│
        └───────┬──────┘
                │
       ┌────────┼────────┐
       ▼        ▼        ▼
    SERVER 1 SERVER 2 SERVER 3

Ahora podemos añadir servidores según aumente la demanda.

4. Arquitectura de nuestra Super Aplicación

Nuestra arquitectura inicial podría ser:

                 INTERNET
                     │
                     ▼
                    CDN
                     │
                     ▼
              LOAD BALANCER
                     │
          ┌──────────┼──────────┐
          ▼          ▼          ▼
       APP #1     APP #2     APP #3
          │          │          │
          └──────────┼──────────┘
                     │
          ┌──────────┼───────────┐
          ▼          ▼           ▼
        CACHE     DATABASE      QUEUE
          │          │           │
        Redis     PostgreSQL   Workers
                                  │
                                  ▼
                             AI GATEWAY
                                  │
                     ┌────────────┼───────────┐
                     ▼            ▼           ▼
                  MODEL A      MODEL B     MODEL C

¿Por qué tantas piezas?

Porque cada componente resuelve un problema diferente.

5. Stateless Applications

Una aplicación stateless no depende de la memoria interna de un servidor para mantener el estado del usuario.

Problema

USER
  │
  ▼
SERVER 1

login realizado

session almacenada
solo en SERVER 1


Siguiente request

  │
  ▼

SERVER 2

¿Quién eres?

Tenemos un problema.

Solución

SERVER 1
   │
   ├─────────────┐
   │             │
   ▼             ▼
Redis         Database
   ▲             ▲
   │             │
   └──────┬──────┘
          │
       SERVER 2

El estado se almacena en una capa compartida.

6. Load Balancing

Un Load Balancer distribuye requests entre múltiples servidores.

Ejemplo

REQUEST 1 → SERVER 1
REQUEST 2 → SERVER 2
REQUEST 3 → SERVER 3
REQUEST 4 → SERVER 1
REQUEST 5 → SERVER 2

Algoritmos

Health Checks

El Load Balancer debe saber si un servidor está vivo.

GET /health

200 OK
{
    "status": "healthy"
}

Si un servidor falla:

SERVER 1 ❌

        ↓

LOAD BALANCER

        ↓

SERVER 2
SERVER 3

7. CDN

Una CDN distribuye contenido geográficamente.

Sin CDN

Madrid
   │
   ▼
Servidor en USA
   │
   ▼
Imagen

Con CDN

Madrid
   │
   ▼
CDN Madrid
   │
   ▼
Imagen

Esto reduce latencia y carga del servidor principal.

¿Qué podemos servir mediante CDN?

• JavaScript;
• CSS;
• imágenes;
• vídeos;
• fuentes;
• archivos públicos.

8. Caching

Caching significa almacenar temporalmente información para no tener que recalcularla o recuperarla continuamente.

Ejemplo

Nuestra aplicación consulta:

"¿Cuáles son las skills
de todos los empleados?"

Si hacemos la consulta 1.000 veces:

1.000 requests
      ↓
PostgreSQL
      ↓
1.000 queries

Podemos cachear:

REQUEST
  ↓
CACHE
  │
  ├── HIT → devolver resultado
  │
  └── MISS
        ↓
    DATABASE
        ↓
      CACHE
        ↓
     RESULT

Cache Hit

El dato está en cache.

Cache Miss

El dato no está y necesitamos consultar la fuente original.

Problema: invalidación

¿Qué ocurre si cambia el dato en PostgreSQL?

El cache podría tener información antigua.

9. Redis

Redis es un sistema de almacenamiento en memoria extremadamente rápido.

Usos habituales

• cache;
• sessions;
• rate limiting;
• queues;
• contadores;
• locks;
• datos temporales.

Ejemplo conceptual

SET employee:123
    "Carlos"

GET employee:123

→ Carlos

TTL

Podemos hacer que un dato expire.

employee:123

TTL = 300 segundos

Esto es muy útil para información temporal.

10. Escalabilidad de PostgreSQL

La base de datos suele convertirse en uno de los primeros cuellos de botella.

Problema

10.000 requests

        ↓

10.000 queries

        ↓

PostgreSQL

        ↓

🔥

Primera solución: índices

Si buscamos continuamente:

WHERE employee_id = 12345

CREATE INDEX
idx_employee_id
ON employees(employee_id);

Pero cuidado

Los índices aceleran lecturas, pero tienen coste de almacenamiento y escritura.

Segunda solución: evitar SELECT *

❌

SELECT *
FROM employees;


✓

SELECT
    id,
    name,
    main_skill
FROM employees;

Tercera solución: paginación

❌

GET /employees

→ 500.000 empleados


✓

GET /employees?page=1&limit=50

11. Connection Pooling

Abrir una conexión a PostgreSQL tiene un coste.

Mal enfoque

REQUEST
 ↓
crear conexión
 ↓
query
 ↓
cerrar conexión

Si recibimos miles de requests, el coste puede ser enorme.

Connection Pool

         CONNECTION POOL

     ┌─────┬─────┬─────┬─────┐
     │ C1  │ C2  │ C3  │ C4  │
     └─────┴─────┴─────┴─────┘
       ↑     ↑     ↑     ↑
       └─────┴─────┴─────┘
              APP

Las conexiones se reutilizan.

20 servidores
×
100 conexiones

=
2.000 conexiones

12. Queues

Una queue permite desacoplar el momento en que se solicita una tarea del momento en que se ejecuta.

Problema

El usuario sube un PDF de 100 MB y queremos analizarlo con IA.

USER
 ↓
UPLOAD
 ↓
AI ANALYSIS
 ↓
RESULT

Si tarda 60 segundos, la experiencia es mala.

Con Queue

USER
 ↓
UPLOAD
 ↓
QUEUE
 ↓
"Procesando..."
 ↓
WORKER
 ↓
AI
 ↓
DATABASE
 ↓
RESULT

El usuario no necesita permanecer bloqueado durante todo el proceso.

13. Workers

Un worker es un proceso que consume trabajos de una cola y los ejecuta.

                QUEUE
                  │
       ┌──────────┼──────────┐
       ▼          ▼          ▼
    WORKER 1   WORKER 2   WORKER 3
       │          │          │
       ▼          ▼          ▼
      AI         AI         AI

Ventaja

Podemos aumentar el número de workers independientemente del frontend.

100 jobs

2 workers
↓
50 jobs / worker


100 jobs

10 workers
↓
10 jobs / worker

14. Event-Driven Architecture

En una arquitectura tradicional:

A
 ↓
B
 ↓
C
 ↓
D

A depende directamente de B, B de C y C de D.

En un sistema orientado a eventos:

             EVENT BUS
          ↗      ↑      ↖
         /       │       \
       A         B         C

Ejemplo

Cuando se crea un empleado:

EMPLOYEE_CREATED

puede provocar:

• actualización del buscador;
• actualización de analytics;
• recalcular recomendaciones;
• notificación;
• actualización de embeddings.

El sistema queda desacoplado.

15. AI Gateway

Una de las piezas más importantes de nuestra Super Aplicación.

Problema

Si cada módulo llama directamente a diferentes proveedores:

SEARCH → Provider A

CHAT → Provider B

AGENT → Provider A

CV → Provider C

REPORT → Provider B

acabamos con:

• credenciales dispersas;
• lógica duplicada;
• costes difíciles de controlar;
• poca observabilidad;
• difícil cambiar de proveedor.

Solución

APPLICATION
     │
     ▼
 AI GATEWAY
     │
     ├── Authentication
     ├── Rate limit
     ├── Logging
     ├── Cost tracking
     ├── Model routing
     ├── Retry
     ├── Fallback
     └── Observability
             │
       ┌─────┼─────┐
       ▼     ▼     ▼
    MODEL A MODEL B MODEL C

16. Model Routing

No todas las tareas necesitan el modelo más potente.

Ejemplo

Router conceptual

REQUEST
   │
   ▼
AI ROUTER
   │
   ├── simple → SMALL
   │
   ├── medium → MEDIUM
   │
   └── complex → LARGE

Esto puede reducir costes drásticamente.

17. Rate Limiting

Un usuario no debería poder realizar 10.000 requests por segundo.

Ejemplo

USER

máximo:

60 requests / minuto

Si supera el límite:

HTTP 429

Too Many Requests

¿Por qué?

• protección contra abuso;
• protección de costes;
• protección del backend;
• protección de proveedores AI;
• estabilidad del sistema.

AI es especialmente sensible

Imaginemos que una llamada AI cuesta €0,05.

1 request = €0,05

1.000 requests = €50

1.000.000 requests = €50.000

18. Procesamiento asíncrono

No todo debe ejecutarse dentro de la petición HTTP.

Síncrono

POST /generate-report

request
  ↓
generate
  ↓
AI
  ↓
PDF
  ↓
response

Asíncrono

POST /generate-report

  ↓

202 Accepted

  ↓

JOB CREATED

  ↓

QUEUE

  ↓

WORKER

  ↓

AI

  ↓

PDF

  ↓

READY

El frontend puede consultar:

GET /jobs/123

{
  "status": "processing"
}

19. Resiliencia

Los sistemas reales fallan.

La pregunta profesional no es:

"¿Cómo evito cualquier fallo?"

sino:

"¿Qué ocurre cuando algo falla?"

Retry

Si una API falla temporalmente:

REQUEST
 ↓
FAIL
 ↓
WAIT
 ↓
RETRY
 ↓
SUCCESS

Exponential Backoff

1ª espera → 1 segundo
2ª espera → 2 segundos
3ª espera → 4 segundos
4ª espera → 8 segundos

¿Por qué no reintentar infinitamente?

Porque podemos amplificar el problema.

Circuit Breaker

NORMAL
  ↓
ERRORS
  ↓
CIRCUIT OPEN
  ↓
NO MORE REQUESTS
  ↓
WAIT
  ↓
TEST
  ↓
CLOSED

Esto evita seguir llamando a un servicio que sabemos que está fallando.

20. Observabilidad

En sistemas pequeños podemos mirar el servidor. En sistemas grandes necesitamos observabilidad.

Las tres grandes señales

Ejemplo de trace

REQUEST 1200 ms

 ├── API        50 ms
 │
 ├── PostgreSQL 100 ms
 │
 ├── Redis       5 ms
 │
 └── AI        1045 ms

Ahora sabemos dónde está el cuello de botella.

Métricas fundamentales

• requests/sec;
• latency;
• error rate;
• CPU;
• memory;
• queue depth;
• database connections;
• AI latency;
• AI errors;
• AI cost.

21. Control de costes AI

Una aplicación tradicional suele tener costes relativamente previsibles. Una aplicación AI puede tener costes variables.

Ejemplo

Usuarios              100.000

Requests/user/día          20

AI requests/día      2.000.000

Coste/request             €0.01

COSTE DIARIO         €20.000

Eso significa aproximadamente:

€20.000 × 30

=

€600.000 / mes

Estrategias

• model routing;
• caching;
• limitar contexto;
• resumir conversaciones;
• batch processing;
• modelos pequeños;
• rate limiting;
• budgets por usuario;
• budgets por organización;
• monitorización.

Cost per user

AI COST / ACTIVE USERS

Cost per successful task

TOTAL AI COST
-------------------------
SUCCESSFUL AI TASKS

22. Backups y Disaster Recovery

Escalar no sirve de nada si perdemos los datos.

Backup

Copia de seguridad de nuestros datos.

RPO

Recovery Point Objective: ¿Cuánto dato podemos permitirnos perder?

RPO = 1 hora

→ como máximo perderíamos
aproximadamente 1 hora de datos.

RTO

Recovery Time Objective: ¿Cuánto tiempo podemos tardar en recuperar el servicio?

RTO = 30 minutos

→ debemos recuperar el sistema
en un máximo aproximado de 30 min.

23. Load Testing

No debemos esperar a producción para descubrir cuánto soporta nuestra aplicación.

Load test

Simulamos tráfico.

100 users
   ↓
500 users
   ↓
1.000 users
   ↓
5.000 users
   ↓
10.000 users

Preguntas

• ¿cuándo aumenta la latencia?
• ¿cuándo aparecen errores?
• ¿qué componente falla primero?
• ¿cuánto CPU utilizamos?
• ¿qué ocurre con PostgreSQL?
• ¿qué ocurre con Redis?
• ¿qué ocurre con la queue?
• ¿qué ocurre con los proveedores AI?

Herramientas

Algunas opciones:

• k6;
• Locust;
• JMeter;
• Artillery.

24. Arquitectura: 100 → 1.000.000 usuarios

Nivel 1 — 100 usuarios

USERS
  ↓
NGINX
  ↓
APP
  ↓
POSTGRESQL
  ↓
AI

No necesitamos Kubernetes, Kafka ni una arquitectura de 50 microservicios.

Nivel 2 — 10.000 usuarios

             LOAD BALANCER
                    │
             ┌──────┴──────┐
             ▼             ▼
           APP 1         APP 2
             │             │
             └──────┬──────┘
                    ▼
                  REDIS
                    │
                    ▼
               POSTGRESQL
                    │
                    ▼
                  QUEUE
                    │
             ┌──────┴──────┐
             ▼             ▼
          WORKER 1      WORKER 2
                         │
                         ▼
                         AI

Nivel 3 — 100.000 usuarios

                    CDN
                     │
                     ▼
               LOAD BALANCER
                     │
       ┌─────────────┼─────────────┐
       ▼             ▼             ▼
    APP 1          APP 2          APP N
       │             │             │
       └─────────────┼─────────────┘
                     │
             ┌───────┼────────┐
             ▼       ▼        ▼
           REDIS   QUEUE   DATABASE
                     │
             ┌───────┼───────┐
             ▼       ▼       ▼
          WORKER   WORKER   WORKER
                     │
                     ▼
                 AI GATEWAY
                     │
             ┌───────┼───────┐
             ▼       ▼       ▼
           SMALL   MEDIUM   LARGE

Nivel 4 — 1.000.000 usuarios

                         INTERNET
                            │
                            ▼
                           CDN
                            │
                            ▼
                    EDGE / WAF
                            │
                            ▼
                     LOAD BALANCER
                            │
              ┌─────────────┼─────────────┐
              ▼             ▼             ▼
          APP CLUSTER   APP CLUSTER   APP CLUSTER
              │             │             │
              └─────────────┼─────────────┘
                            │
                  ┌─────────┼─────────┐
                  ▼         ▼         ▼
                CACHE     QUEUES    SERVICES
                  │         │         │
                  │         ▼         │
                  │      WORKERS      │
                  │         │         │
                  └─────────┼─────────┘
                            ▼
                       AI GATEWAY
                            │
                ┌───────────┼───────────┐
                ▼           ▼           ▼
             MODEL A     MODEL B     MODEL C
                            │
                            ▼
                      OBSERVABILITY
                            │
                 ┌──────────┼──────────┐
                 ▼          ▼          ▼
               LOGS      METRICS     TRACES

25. Herramientas que debes conocer

Docker Compose

Nuestra Super Aplicación podría tener:

services:

  app:
    ...

  postgres:
    ...

  redis:
    ...

  worker:
    ...

  nginx:
    ...

La idea importante

No necesitas memorizar configuraciones. Debes ser capaz de explicar:

"Quiero una aplicación,
una base de datos,
un Redis
y un worker."

Y después utilizar IA para ayudarte a construir la configuración.

26. Utilizar IA como arquitecto

Actúa como un Staff Software Engineer
especializado en sistemas distribuidos.

Esta es la arquitectura de mi aplicación:

[PEGAR ARQUITECTURA]

Actualmente tengo:

- [X] usuarios
- [X] requests/minuto
- [X] AI requests/día
- PostgreSQL
- Redis
- [OTROS]

Analiza:

1. cuellos de botella
2. puntos únicos de fallo
3. problemas de escalabilidad
4. problemas de seguridad
5. problemas de costes
6. problemas de observabilidad

No propongas tecnologías
innecesarias.

Prioriza las mejoras.

Tengo:

100.000 usuarios

20 requests por usuario/día

30% de requests utilizan IA.

Quiero estimar:

- requests/día
- requests/segundo
- AI requests/día
- capacidad de servidores
- carga de PostgreSQL
- carga de Redis
- jobs de background
- coste potencial de IA

Indica todas las hipótesis
que estás utilizando.

No inventes precios actuales.
Si necesitas precios,
indica qué dato debo proporcionar.

Tengo estos datos:

API latency: 2.1 s
Database: 80 ms
Redis: 5 ms
AI: 1.8 s
CPU: 35%
Memory: 40%

Identifica el cuello de botella.

Explica:

- por qué
- qué NO debería optimizar todavía
- qué optimizarías primero
- cómo lo medirías

Tengo una funcionalidad AI.

Actualmente:

100.000 usuarios
15 requests AI/user/month
coste medio €0.04/request

Analiza el coste mensual.

Después propón
al menos 10 estrategias
para reducirlo.

Clasifícalas:

- arquitectura
- modelo
- prompting
- caching
- producto

No sacrifiques calidad
sin explicarlo.

Simula un incidente de producción.

Nuestra aplicación tiene:

CDN
Load Balancer
3 servidores
Redis
PostgreSQL
Queue
Workers
AI Gateway

A las 10:00 aumenta el tráfico
10 veces.

Quiero que simules:

10:00
10:05
10:10
10:15
10:30

Para cada momento indica:

- síntomas
- métricas
- componente afectado
- hipótesis
- acción
- consecuencia

Al final crea
un postmortem.

27. Ejercicios prácticos

202 Accepted

job_id: 123

status: processing

10.000 / 10

= 1.000 minutos

≈ 16,7 horas

16,7 / 10
≈ 1,67 horas

500.000 × €0,02

= €10.000

RPO = 15 minutos

RTO = 1 hora

API       100 ms
Redis      10 ms
Database   90 ms
AI       4.7 s

NGINX
 ↓
APP
 ↓
POSTGRESQL
 ↓
AI

28. Test autocorregible

30 preguntas · objetivo mínimo: 80%

29. Proyecto Week 22

Fase 1 — Arquitectura actual

Documenta la arquitectura que tenemos en este momento.

Fase 2 — Identificar cuellos de botella

Para cada componente:

Fase 3 — Crear Docker Compose

El entorno local debería tener, como mínimo:

app
postgres
redis
worker
nginx

Fase 4 — Añadir Queue

Implementa un proceso:

USER
 ↓
CREATE JOB
 ↓
QUEUE
 ↓
WORKER
 ↓
AI
 ↓
DATABASE
 ↓
RESULT

Fase 5 — AI Gateway

Todas las llamadas AI deberán pasar por una capa centralizada.

Fase 6 — Model Router

Define:

• modelo barato;
• modelo medio;
• modelo avanzado.

Y crea reglas para decidir cuál utilizar.

Fase 7 — Rate Limiting

Implementa límites para:

• usuario;
• organización;
• IP;
• endpoint AI.

Fase 8 — Observabilidad

Registra:

• latencia;
• errores;
• requests;
• AI calls;
• AI cost;
• queue depth;
• database latency.

Fase 9 — Load Test

Realiza pruebas progresivas:

100 users
 ↓
500
 ↓
1.000
 ↓
5.000
 ↓
10.000

Fase 10 — Simulación de incidente

Provoca uno de estos escenarios:

• PostgreSQL lento;
• Redis caído;
• AI provider caído;
• queue saturada;
• worker detenido;
• pico de tráfico.

Documenta:

INCIDENT

Detection
↓
Diagnosis
↓
Mitigation
↓
Recovery
↓
Root Cause
↓
Prevention

Entregables

• Architecture Diagram;
• Architecture Decision Records;
• Docker Compose;
• Redis;
• Queue;
• Worker;
• AI Gateway;
• Model Router;
• Rate Limiting;
• Observability;
• Load Test;
• Cost Model;
• Incident Simulation;
• Disaster Recovery Plan.

30. Architecture Decision Records

Una habilidad importante de un ingeniero senior es documentar por qué se tomó una decisión.

Ejemplo ADR

# ADR-001

Título:
Utilizar Redis como cache

Contexto:

La aplicación realiza
consultas repetitivas.

Decisión:

Utilizar Redis.

Alternativas:

- cache local
- PostgreSQL
- Memcached

Consecuencia:

Reducimos latencia y carga
sobre PostgreSQL.

Riesgo:

Datos potencialmente obsoletos.

Mitigación:

TTL + invalidación.

Haz al menos cinco ADR para la Super Aplicación.

31. Reto de nivel Staff Engineer

1.000 requests/minuto

100.000 requests/minuto

Tu respuesta debe incluir:

1. qué monitorizas primero;
2. qué componente puede fallar;
3. qué limitas;
4. qué desactivas temporalmente;
5. qué escalas;
6. qué cacheas;
7. qué procesos pasas a async;
8. cómo proteges PostgreSQL;
9. cómo proteges el proveedor AI;
10. cómo controlas costes;
11. cómo comunicas el incidente;
12. cómo recuperas el sistema;
13. qué cambiarías posteriormente.

1. Detectar

   Metrics
   Logs
   Alerts


2. Proteger

   Rate limiting
   WAF
   Throttling


3. Reducir carga

   Cache
   Disable expensive features
   Async processing


4. Escalar

   App instances
   Workers


5. Proteger DB

   Connection limits
   Cache
   Read replicas


6. Proteger AI

   Model routing
   Budgets
   Queue


7. Recuperar

   Gradual rollout


8. Postmortem

   Root cause
   Prevention

32. Referencias externas

33. Checklist de Week 22

34. Criterios para superar Week 22

35. Preparación para Week 23