Colas, rate limits y caché

Los modelos son lentos y caros comparados con una función normal. Si varias personas los usan a la vez, necesitas colas, límites, reintentos y caché antes de que llegue el susto.

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

Terminal

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: 300

Caché 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.

← Observabilidad Proyecto producción →