Week 19 — Producción, Escalabilidad y Resiliencia

1. Objetivos de Week 19

Al terminar esta semana deberás entender:

• qué diferencia hay entre prototipo y producción;
• qué significa escalar una aplicación;
• qué es procesamiento síncrono;
• qué es procesamiento asíncrono;
• qué es una cola;
• qué es un worker;
• qué es caching;
• qué es rate limiting;
• qué significa resiliencia;
• cómo diseñar reintentos;
• cómo gestionar errores;
• qué es observabilidad;
• qué son logs;
• qué son métricas;
• qué es distributed tracing;
• cómo controlar costes de IA;
• cómo desplegar una aplicación;
• cómo crear health checks;
• cómo utilizar IA para diseñar sistemas de producción.

2. Prototype vs Production

Esta distinción es fundamental.

Prototipo

USER
 ↓
API
 ↓
LLM
 ↓
ANSWER

Puede ser suficiente para demostrar una idea.

Producción

USER
 ↓
LOAD BALANCER
 ↓
API
 ↓
AUTH
 ↓
RATE LIMIT
 ↓
QUEUE
 ↓
WORKERS
 ↓
LLM
 ↓
RAG
 ↓
MEMORY
 ↓
TOOLS
 ↓
DATABASE
 ↓
OBSERVABILITY

La complejidad aumenta porque ahora debemos preocuparnos por situaciones que en un prototipo normalmente ignoramos.

3. Arquitectura de producción

Vamos a evolucionar nuestra arquitectura.

                         USERS
                           │
                           ↓
                    LOAD BALANCER
                           │
                           ↓
                    API GATEWAY
                           │
          ┌────────────────┼────────────────┐
          ↓                ↓                ↓
        AUTH           RATE LIMIT        CACHE
          │                │                │
          └────────────────┼────────────────┘
                           ↓
                      APPLICATION
                           │
             ┌─────────────┼─────────────┐
             ↓             ↓             ↓
           AGENT          RAG          MEMORY
             │
             ↓
           TOOLS
             │
             ↓
          QUEUES
             │
       ┌─────┼─────┐
       ↓     ↓     ↓
    WORKER WORKER WORKER
       │     │     │
       └─────┼─────┘
             ↓
        EXTERNAL AI
             │
             ↓
        DATABASES
             │
             ↓
      OBSERVABILITY

4. ¿Qué significa escalar?

Supongamos que nuestra aplicación tiene un único usuario.

1 USER
 ↓
1 SERVER

Funciona perfectamente.

Ahora llegan 1.000 usuarios.

1000 USERS
     ↓
     ?

El servidor puede no ser capaz de procesar todas las solicitudes.

Escalado vertical

SERVER
4 CPU
16 GB RAM

        ↓

SERVER
16 CPU
64 GB RAM

Escalado horizontal

             LOAD BALANCER
                    │
       ┌────────────┼────────────┐
       ↓            ↓            ↓
    SERVER 1     SERVER 2     SERVER 3

5. Procesamiento síncrono vs asíncrono

Síncrono

USER
 ↓
REQUEST
 ↓
PROCESS
 ↓
WAIT
 ↓
ANSWER

El usuario permanece esperando.

Problema

Imaginemos que subir y procesar un PDF tarda 45 segundos.

USER
 ↓
UPLOAD
 ↓
PROCESS 45 seconds
 ↓
RESPONSE

La experiencia es mala.

Asíncrono

USER
 ↓
UPLOAD
 ↓
CREATE JOB
 ↓
"Procesando..."
 ↓
RETURN JOB ID

Después:

JOB
 ↓
QUEUE
 ↓
WORKER
 ↓
PROCESS
 ↓
DATABASE
 ↓
READY

El usuario puede continuar utilizando la aplicación.

6. Colas y workers

Una cola es una estructura que permite poner trabajos pendientes.

QUEUE

[Job 1]
[Job 2]
[Job 3]
[Job 4]
[Job 5]

Los workers procesan esos trabajos.

             QUEUE
               │
       ┌───────┼───────┐
       ↓       ↓       ↓
    WORKER1 WORKER2 WORKER3

Ejemplo

100 usuarios suben documentos.

100 UPLOADS
     ↓
100 JOBS
     ↓
QUEUE
     ↓
WORKERS

Los trabajos se procesan de forma controlada.

Ventaja

• desacoplamiento;
• control de carga;
• reintentos;
• procesamiento paralelo;
• procesamiento asíncrono.

Ejemplos de tecnologías

• Redis + workers;
• RabbitMQ;
• Amazon SQS;
• Google Cloud Pub/Sub;
• Kafka;
• Celery;
• BullMQ.

7. Caching

Una cache evita realizar trabajo innecesario.

Ejemplo

El usuario pregunta:

¿Cuál es la política de vacaciones?

Nuestro sistema realiza:

QUESTION
 ↓
RAG
 ↓
LLM
 ↓
ANSWER

Si 1.000 usuarios preguntan exactamente lo mismo, podríamos estar repitiendo trabajo.

Podemos utilizar cache.

QUESTION
 ↓
CACHE?
 │
 ├── YES → ANSWER
 │
 └── NO
      ↓
     RAG
      ↓
     LLM
      ↓
    CACHE
      ↓
    ANSWER

Tipos de cache

• cache de respuestas;
• cache de embeddings;
• cache de documentos;
• cache de resultados de Tools;
• cache de sesiones;
• cache de configuración.

8. Rate limiting

Rate limiting significa limitar cuántas solicitudes puede realizar un usuario durante un periodo.

Ejemplo

USER A

100 requests / minute

LIMIT:
20 requests / minute

La solicitud número 21 puede ser rechazada temporalmente.

¿Por qué?

• proteger infraestructura;
• evitar abuso;
• controlar costes;
• evitar saturación;
• proteger proveedores de IA.

Rate limit por usuario

USER A → 100 requests
USER B → 100 requests
USER C → 100 requests

Rate limit por endpoint

/chat
100/min

/upload
20/min

/expensive-analysis
5/min

9. Resiliencia

Una aplicación de producción debe asumir que las cosas fallarán.

¿Qué puede fallar?

• API de IA;
• base de datos;
• Redis;
• red;
• servicio externo;
• worker;
• archivo;
• timeout;
• credenciales;
• servidor.

Diseño ingenuo

CALL LLM
 ↓
ERROR
 ↓
APPLICATION FAILS

Diseño resiliente

CALL LLM
 ↓
ERROR
 ↓
RETRY?
 │
 ├── YES
 │    ↓
 │   RETRY
 │
 └── NO
      ↓
   FALLBACK
      ↓
   ERROR CONTROLADO

Retry

Podemos volver a intentar una operación que ha fallado.

Pero cuidado.

RETRY
RETRY
RETRY
RETRY
RETRY
...

Esto puede empeorar el problema.

Exponential backoff

Intento 1
↓
1 segundo

Intento 2
↓
2 segundos

Intento 3
↓
4 segundos

Intento 4
↓
8 segundos

10. Gestión profesional de errores

No todos los errores son iguales.

Mala experiencia

ERROR 500

Mejor experiencia

No hemos podido completar
el análisis en este momento.

Hemos registrado el incidente.
Puedes volver a intentarlo.

Pero internamente...

ERROR_ID:
INC-2026-008392

SERVICE:
document-analysis

USER:
12345

MODEL:
...

LATENCY:
...

ERROR:
timeout

11. Observabilidad

Observabilidad significa poder entender qué está ocurriendo dentro del sistema.

                 OBSERVABILITY

             ┌───────┼───────┐
             ↓       ↓       ↓
           LOGS   METRICS  TRACES
             │       │       │
             └───────┼───────┘
                     ↓
                 DASHBOARD
                     ↓
                   ALERTS

12. Logs

Un log es un registro de lo que ha ocurrido.

Mala práctica

print("error")

Mejor

{
  "timestamp": "...",
  "level": "ERROR",
  "service": "agent",
  "operation": "call_llm",
  "user_id": "...",
  "request_id": "...",
  "error": "timeout"
}

¿Qué debemos registrar?

• request ID;
• usuario o tenant anonimizado cuando proceda;
• servicio;
• operación;
• duración;
• resultado;
• errores;
• modelo utilizado;
• tokens cuando esté disponible;
• coste estimado.

13. Métricas

Una métrica es un valor cuantificable.

Ejemplos

Dashboard

REQUESTS
1,248/min

ERROR RATE
1.7%

P95 LATENCY
1.8 sec

QUEUE
84 jobs

AI COST
€32.40

ACTIVE USERS
218

14. Distributed tracing

Imaginemos que una pregunta tarda 12 segundos.

¿Dónde están esos 12 segundos?

REQUEST
│
├── AUTH
│   └── 30ms
│
├── RAG
│   └── 200ms
│
├── MEMORY
│   └── 50ms
│
├── TOOL
│   └── 500ms
│
└── LLM
    └── 11.2s

Ahora sabemos que el problema está en el LLM.

Trace

TRACE_ID: abc123

request
 ├─ auth
 ├─ memory
 ├─ rag
 │   └─ vector_search
 ├─ tool
 └─ llm

Esto es especialmente útil cuando tenemos muchos servicios.

15. Costes de IA en producción

Una aplicación AI puede funcionar perfectamente y aun así ser económicamente inviable.

Ejemplo

Supongamos:

10.000 usuarios

cada uno:
10 requests/día

TOTAL:
100.000 requests/día

Si cada request tiene un coste medio de €0,02:

100.000 × €0,02

= €2.000 / día

El número es hipotético, pero la idea es fundamental.

Debemos medir

• requests;
• tokens;
• modelo;
• input;
• output;
• cache hits;
• coste por usuario;
• coste por funcionalidad.

Cost per feature

CHAT
€0.001/request

DOCUMENT ANALYSIS
€0.08/document

VIDEO ANALYSIS
€0.70/video

Esto permite tomar decisiones de producto.

16. Deployment

Desplegar significa hacer que nuestra aplicación esté disponible para usuarios reales.

Entorno local

YOUR COMPUTER
 ↓
localhost

Producción

INTERNET
 ↓
DOMAIN
 ↓
REVERSE PROXY
 ↓
APPLICATION
 ↓
DATABASE

Entornos

Principio fundamental

Pipeline conceptual

CODE
 ↓
GIT
 ↓
TESTS
 ↓
BUILD
 ↓
STAGING
 ↓
VALIDATION
 ↓
PRODUCTION

17. Health checks

Nuestra infraestructura necesita saber si un servicio está funcionando.

Health check

GET /health

{
  "status": "ok"
}

Pero podemos ir más allá

{
  "application": "ok",
  "database": "ok",
  "redis": "ok",
  "queue": "ok",
  "llm": "ok"
}

Readiness vs liveness

Una aplicación puede estar viva pero no estar preparada para recibir tráfico.

LIVENESS
¿Estoy vivo?

READINESS
¿Estoy preparado?

18. Utilizar IA para construir sistemas de producción

Aquí aparece una de las habilidades más importantes de todo el curso.

No queremos utilizar la IA solamente para generar código.

Queremos utilizarla como arquitecto, reviewer, tester, analista y copiloto técnico.

Actúa como un arquitecto de software
especializado en aplicaciones AI.

Esta es mi arquitectura:

[PEGAR ARQUITECTURA]

Analiza:

1. escalabilidad
2. seguridad
3. disponibilidad
4. latencia
5. costes
6. observabilidad
7. puntos únicos de fallo
8. gestión de errores
9. concurrencia
10. recuperación ante fallos

No generes código todavía.

Quiero primero un análisis crítico.

Analiza mi aplicación AI
como si fueras responsable
de aprobarla para producción.

Genera una checklist que cubra:

- authentication
- authorization
- secrets
- rate limiting
- logging
- monitoring
- tracing
- backups
- database
- queues
- retries
- timeouts
- caching
- cost control
- testing
- deployment
- rollback
- disaster recovery

Clasifica cada punto como:

CRITICAL
HIGH
MEDIUM
LOW

Quiero comprobar la resiliencia
de mi aplicación AI.

Simula conceptualmente
estos fallos:

- LLM unavailable
- database unavailable
- Redis unavailable
- queue unavailable
- timeout
- high traffic
- invalid file
- huge file
- repeated requests

Para cada escenario:

1. qué ocurre;
2. qué debería ocurrir;
3. cómo detectarlo;
4. cómo recuperarnos;
5. qué test implementar.

19. Ejemplos completos

Ejemplo 1 — PDF

USER
 ↓
UPLOAD
 ↓
VALIDATION
 ↓
CREATE JOB
 ↓
QUEUE
 ↓
WORKER
 ↓
PDF PROCESSOR
 ↓
OCR / VISION
 ↓
CHUNKING
 ↓
EMBEDDINGS
 ↓
VECTOR DB
 ↓
READY

Ejemplo 2 — Pregunta al Agent

USER
 ↓
AUTH
 ↓
RATE LIMIT
 ↓
CACHE
 ↓
MEMORY
 ↓
RAG
 ↓
AGENT
 ↓
TOOL
 ↓
LLM
 ↓
ANSWER

Ejemplo 3 — LLM caído

AGENT
 ↓
LLM
 ↓
TIMEOUT
 ↓
RETRY
 ↓
TIMEOUT
 ↓
FALLBACK MODEL
 ↓
ANSWER

Ejemplo 4 — Worker caído

QUEUE
 ↓
WORKER 1
 ↓
CRASH

JOB REMAINS

QUEUE
 ↓
WORKER 2
 ↓
PROCESS

Ejemplo 5 — Demasiados usuarios

1000 USERS
 ↓
LOAD BALANCER
 ↓
SERVER 1
SERVER 2
SERVER 3
SERVER 4
 ↓
QUEUE
 ↓
WORKERS

20. Ejercicios prácticos

UPLOADS
 ↓
VALIDATION
 ↓
1000 JOBS
 ↓
QUEUE
 ↓
WORKERS
 ↓
PROCESSING
 ↓
DATABASE
 ↓
STATUS = READY

CHAT
UPLOAD
VIDEO ANALYSIS

CHAT
100 requests/min

UPLOAD
20 uploads/min

VIDEO ANALYSIS
5 jobs/min

USER
 ↓
LOAD BALANCER
 ↓
API
 ↓
AUTH
 ↓
RATE LIMIT
 ↓
CACHE
 ↓
AGENT
 ├── MEMORY
 ├── RAG
 └── TOOLS
 ↓
QUEUE
 ↓
WORKERS
 ↓
AI SERVICES
 ↓
DATABASE
 ↓
OBSERVABILITY

UPLOAD
 ↓
VALIDATION
 ↓
CREATE JOB
 ↓
202 ACCEPTED
 ↓
JOB ID
 ↓
QUEUE
 ↓
WORKER
 ↓
VIDEO PROCESSING
 ↓
TRANSCRIPTION
 ↓
FRAME ANALYSIS
 ↓
SUMMARY
 ↓
DATABASE
 ↓
STATUS = READY
 ↓
NOTIFICATION

21. Test autocorregible

Objetivo para superar la semana: 80%.

22. Proyecto Week 19

Objetivo

Implementar una primera arquitectura de producción alrededor del sistema que hemos construido durante las semanas anteriores.

Debe incluir

• API protegida;
• rate limiting;
• logging estructurado;
• health checks;
• gestión de errores;
• timeouts;
• retry limitado;
• cache donde tenga sentido;
• cola de trabajos;
• workers;
• procesamiento asíncrono de documentos;
• métricas;
• cost tracking;
• monitorización;
• documentación de arquitectura.

Arquitectura objetivo

                         USERS
                           │
                           ↓
                    REVERSE PROXY
                           │
                           ↓
                         API
                           │
             ┌─────────────┼─────────────┐
             ↓             ↓             ↓
           AUTH        RATE LIMIT       CACHE
             │             │             │
             └─────────────┼─────────────┘
                           ↓
                         AGENT
                           │
              ┌────────────┼────────────┐
              ↓            ↓            ↓
            MEMORY        RAG         TOOLS
                           │
                           ↓
                         QUEUE
                           │
                  ┌────────┼────────┐
                  ↓        ↓        ↓
               WORKER1  WORKER2  WORKER3
                  │        │        │
                  └────────┼────────┘
                           ↓
                       AI SERVICES
                           │
                           ↓
                        DATABASE
                           │
                           ↓
                     OBSERVABILITY

Feature 1 — Job system

Implementa un sistema de trabajos para operaciones largas.

POST /jobs

{
  "type": "document_analysis",
  "file_id": "..."
}

Respuesta:

{
  "job_id": "...",
  "status": "queued"
}

Feature 2 — Job status

GET /jobs/{id}

{
  "status": "processing",
  "progress": 62
}

Feature 3 — Estados

CREATED
   ↓
QUEUED
   ↓
PROCESSING
   ↓
COMPLETED

          ↘ FAILED

Feature 4 — Retry

Los trabajos fallidos temporalmente deben poder reintentarse.

Feature 5 — Observabilidad

Cada job debe tener:

• job_id;
• request_id;
• timestamps;
• status;
• duration;
• error;
• retry_count;
• cost.

Feature 6 — Dashboard

Crea una pequeña pantalla de administración:

JOBS

Queued       24
Processing   12
Completed    842
Failed       17

ERROR RATE
1.8%

AVG LATENCY
2.4 sec

AI COST TODAY
€18.43

Tests del proyecto

Entregables

• diagrama de arquitectura;
• API;
• queue;
• worker;
• job system;
• retry system;
• logging;
• metrics;
• health checks;
• cost tracking;
• dashboard;
• tests;
• documentación.

23. Reto avanzado — ¿Qué pasa si...?

Escenario A

El proveedor de IA deja de responder durante 10 minutos.

Escenario B

10.000 usuarios suben documentos simultáneamente.

Escenario C

Un worker procesa incorrectamente un documento.

24. Recursos externos

25. Checklist Week 19

26. Criterios para superar Week 19

27. Preparación para Week 20

                 SUPER APP

                      │
                      ↓
                 TRUST BOUNDARY
                      │
          ┌───────────┼───────────┐
          ↓           ↓           ↓
       USER INPUT   FILES       TOOLS
          │           │           │
          └───────────┼───────────┘
                      ↓
                 SECURITY LAYER
                      │
                      ↓
                    AGENT
                      │
                      ↓
                   ACTIONS