Procesamiento Asíncrono en Serverless: Cloudflare Queues y Dead Letter Queues

Equipo NuxfireSeptember 15th, 2026
Procesamiento Asíncrono en Serverless: Cloudflare Queues y Dead Letter Queues

En el desarrollo de aplicaciones web modernas, nada degrada más la experiencia del usuario que las pantallas bloqueadas esperando operaciones lentas.

Ya sea esperar 15 segundos la respuesta de un modelo de lenguaje (un LLM como Claude o GPT-4), generar un informe en PDF o enviar cientos de correos transaccionales, procesar tareas pesadas de forma síncrona dentro de la petición HTTP es una receta segura para los timeouts y los fallos de conexión.

En Nuxfire, todo el procesamiento en segundo plano lo gestionan de forma resiliente Cloudflare Queues y las Dead Letter Queues (DLQ).


La Arquitectura Productor-Consumidor Serverless

En las arquitecturas tradicionales, configurar colas exigía alojar instancias de RabbitMQ o administrar colas Redis BullMQ con workers de Node.js monitoreados por PM2.

Con Cloudflare Queues, la infraestructura es 100 % serverless:

  1. Productor: El dashboard o la API encola mensajes en milisegundos y devuelve una respuesta inmediata (202 Accepted) al usuario.
  2. Cola (Queue): Cloudflare almacena los mensajes con garantía de entrega y control de concurrencia.
  3. Consumidor (Worker): Un worker dedicado procesa los lotes de mensajes en segundo plano con reintentos automáticos.
// Encolando un job asíncrono desde una API de Nuxt 4
export default defineEventHandler(async (event) => {
  const body = await readBody(event);
  
  // Publica en la cola de Cloudflare en menos de 10 ms
  await env.APP_QUEUE.send({
    type: "PROCESS_AI_COMPLETION",
    payload: {
      documentId: body.documentId,
      prompt: body.prompt
    },
    enqueuedAt: Date.now()
  });

  return { success: true, message: "Procesamiento iniciado en segundo plano." };
});

Resiliencia con Backoff Exponencial y Dead Letter Queue (DLQ)

¿Y si una API externa de IA o un proveedor de correo está temporalmente fuera de servicio?

En Nuxfire, las colas se configuran en SST con una política estricta de tolerancia a fallos:

  • Reintentos automáticos: El consumidor intenta reprocesar el mensaje hasta 3 veces con intervalos graduales (Backoff Exponencial).
  • Dead Letter Queue (DLQ): Si el fallo persiste tras los intentos máximos, ¡el mensaje no se pierde! Se envía automáticamente a una cola de cuarentena (DLQ).
  • Inspección y Alerta: El equipo de soporte puede inspeccionar los mensajes en la DLQ, corregir el problema de integración y volver a encolar los mensajes con seguridad.
// infra/queue.ts usando SST v4
export const appQueue = new sst.cloudflare.Queue("AppQueue", {
  dlq: new sst.cloudflare.Queue("AppQueueDLQ")
});

Tareas Periódicas con el CRON Worker

Además de las colas orientadas a eventos, muchos SaaS necesitan rutinas programadas:

  • Verificar las facturas vencidas en Stripe.
  • Limpiar los tokens de invitación expirados.
  • Consolidar las métricas de uso diario de tokens de IA.

Nuxfire incluye un CRON Worker nativo configurado en apps/functions, que se dispara cada hora sin depender de servicios externos como Cronhook ni de instancias de cron en Linux.

Construye sistemas distribuidos profesionales sin sorpresas operativas.

Accede ahora mismo al monorepo de Nuxfire con entrega inmediata y soporte en el Grupo VIP →