Objetivos de aprendizaje
- Separar peticiones interactivas de trabajos pesados.
- Aplicar rate limits por usuario, equipo o tenant.
- Usar caché sin romper seguridad ni frescura de datos.
En cristiano: cola. Es una lista ordenada de trabajos. En vez de intentar hacerlo todo al mismo tiempo, los trabajos entran, esperan y se procesan con control.
Qué va en cola y qué no
- Interactivo: chat, autocomplete, acciones que el usuario espera en pantalla.
- Cola: resumir 100 PDFs, generar audios, procesar vídeos, evaluar muchos prompts.
- Programado: reindexar documentos, recalcular embeddings, ejecutar evals nocturnas.
Idea clave. BullMQ documenta colas sobre Redis con rate limiting. Para apps Node, es una pieza sencilla para trabajos en segundo plano.
Rate limit conceptual
limites:
usuario_gratis:
requests_minuto: 10
tokens_dia: 20000
equipo_interno:
requests_minuto: 60
tokens_dia: 500000
trabajos_pesados:
concurrencia: 2
reintentos: 1
timeout_segundos: 300Caché responsable
- Cachea respuestas públicas o preguntas repetidas sin datos privados.
- No cachees respuestas con datos personales sin diseño explícito.
- Incluye modelo, prompt version y permisos en la clave de caché.
- Invalida caché cuando cambian documentos o políticas.
Cuidado. Una caché mal diseñada puede filtrar respuestas de un usuario a otro. En RAG multiusuario, la caché debe incluir tenant, permisos y versión de documentos.
Comprueba que funciona. Simula 50 peticiones. El sistema debe rechazar, encolar o degradar con mensaje claro; nunca quedarse colgado sin explicación.
Guardar y reabrir el proyecto.
Coste y latencia se diseñan. Si esperas a tener usuarios para pensar en límites, llegarás tarde.
Siguiente misión recomendada
Si has guardado la evidencia de esta lección, continúa con «Proyecto producción». Si no, repite la comprobación antes de avanzar.