Vercel y los trabajos en segundo plano: cómo organizar colas, cron y tareas largas
Publicado el 2026-11-14 por frfrand
Arquitectura práctica para separar frontend, funciones HTTP, jobs, colas y workers cuando las tareas no encajan en el tiempo de ejecución de Vercel.
Vercel es una buena opción para desplegar frontends y funciones HTTP, pero una función HTTP no es necesariamente un worker permanente. Si tu aplicación debe generar informes largos, procesar miles de documentos o consumir una cola de manera continua, conviene diseñar la ejecución explícitamente.
1. Distingue cuatro tipos de trabajo
| Necesidad | Patrón habitual | |---|---| | Respuesta inmediata | Función HTTP pequeña | | Procesamiento desacoplado | Encolar trabajo y responder con identificador | | Ejecución periódica | Programador que activa una tarea | | Proceso que escucha una cola todo el día | Worker residente en servicio apto para ello |
Una función tiene un máximo de duración sujeto a runtime, configuración y plan; excederlo causa un error. No afirmes que todas las funciones de Vercel tienen el mismo límite: los valores cambian con Fluid Compute y el plan.
2. Diseña tareas reintentables
Para exportar miles de filas, el endpoint HTTP valida permisos, crea un registro job en PostgreSQL, publica un mensaje en la cola y responde 202 Accepted con el ID. El worker procesa y actualiza estados como queued, running, completed y failed.
Los usuarios consultan el estado mediante un endpoint; descargar el resultado debe usar almacenamiento apropiado y una URL con caducidad si hay información privada.
3. Idempotencia y fallos
Una cola puede entregar mensajes más de una vez. Identifica cada tarea, impide cobrar o enviar comunicaciones duplicadas y define reintentos con backoff. Registra la causa del fallo y crea una cola de errores para los elementos que agotaron los intentos. Mantén los secretos en el servidor y verifica los permisos antes de permitir consultar el resultado.
Si la tarea dura minutos u horas, no la mantengas artificialmente abierta dentro de una solicitud. Divide en bloques o usa un trabajador adecuado al tiempo y la memoria requeridos.
4. Qué hacer con cron
Los trabajos cron de una plataforma suelen disparar invocaciones, no garantizar que un proceso de aplicación permanezca activo entre ejecuciones. Protege el punto de conexión de cron, maneja las superposiciones y almacena un cursor o marca del último trabajo; un proceso reiniciado no debe repetir todo.
5. Arquitectura híbrida
Una arquitectura válida es: frontend Next.js en Vercel → API y PostgreSQL → cola Redis o equivalente → trabajador en VPS. También puedes conservar la API en Vercel si sus tiempos y límites se ajustan a tu aplicación. No introduzcas Redis sin una necesidad concreta: una tabla de trabajos en PostgreSQL puede bastar al principio.
Para implementar esta separación revisa Vercel con backend y PostgreSQL en ArduMaker, ArduMaker frente a Vercel y automatizaciones y tareas cron.
Preguntas frecuentes
### ¿No puedo hacer trabajos largos en Vercel? Algunos sí, siempre que se respeten límites, configuración y comportamiento del runtime.
¿Un cron equivale a un worker?
No; un cron programa ejecuciones, mientras un worker puede consumir trabajo continuamente.
¿Redis es obligatorio?
No; depende del volumen, la semántica de cola y los requisitos operativos.
Fuentes: Límites de Vercel Functions y configurar duración.