Automatizar procesos de larga duración con múltiples pausas, reintentos y validaciones es uno de los mayores desafíos en arquitecturas modernas. Los workflows de Cloudflare ofrecen una solución robusta para orquestar estos flujos sin depender de colas simples o arquitecturas tradicionales, y aquí se explica cómo implementar un proceso de onboarding completo con recordatorios inteligentes.
¿Qué problema resuelven los workflows en procesos de onboarding?
Hasta este punto del proyecto, el flujo incluye un registro con email y avatar, el envío de un correo mediante Resend y la generación de un JWT para autenticar comentarios. Sin embargo, no existe ningún mecanismo de seguimiento hacia el usuario registrado [01:00].
El workflow resuelve esto creando un proceso de onboarding automatizado que funciona así:
- Registra al usuario y envía un mensaje de bienvenida.
- Espera un tiempo determinado.
- Valida si una propiedad nueva en base de datos cambió respecto a su valor inicial.
- Si no hubo cambio, envía un recordatorio.
- Reintenta el proceso con intervalos crecientes hasta detectar actividad.
Este tipo de flujos con pausas prolongadas, validaciones intermedias y múltiples interacciones con servidores son exactamente el caso de uso donde los workflows brillan, incluso cuando se necesita la aprobación de un humano [01:30].
¿Cuáles son los límites críticos que debes conocer?
Antes de implementar cualquier solución, revisar los límites es fundamental porque determinan si tu caso de uso es viable en la plataforma [02:08].
¿Qué ofrece la capa gratuita frente a la paga?
- 100 scripts disponibles con un máximo de 3 MB por definición en la capa gratuita y 10 MB en la paga.
- Persistencia máxima: 100 MB en free y 1 GB en la capa paga. Cuando un workflow está pausado, deja de facturar y entra en reposo; al reiniciarse, vuelve a montar la información en memoria [02:50].
- Tiempo máximo de espera por step: un año completo.
- Ejecuciones diarias: 100 en la capa gratuita, ilimitadas en la paga.
- Concurrencia: 100 ejecuciones simultáneas en free y 10,000 en la paga [03:30].
Este límite de concurrencia es especialmente relevante. Si tu aplicación se vuelve viral y el usuario 10,001 intenta registrarse al mismo tiempo que los demás, necesitas una estrategia complementaria como combinar workflows con colas, donde la cola drena registros gradualmente y el workflow los procesa [03:55].
Otro límite estricto es la cantidad de subrequests: 50 en la capa gratuita y 10,000 en la paga, configurable hasta 10 millones mediante un formulario de solicitud a Cloudflare [04:20].
¿Cómo se ve el workflow en producción?
Una vez desplegado, el archivo wrangler incluye un objeto de workflow con nombre, binding y clase. Al probarlo en el panel de Cloudflare, aparece un diagrama visual en modo beta que muestra todo el flujo [05:15]:
- Envía el mensaje de welcome.
- Espera 30 minutos.
- Verifica si hubo actividad o comentarios.
- Si no, envía un follow-up.
- Espera 24 horas para evitar spam.
- Repite la verificación, espera siete días y envía un último recordatorio.
Cada ejecución completada muestra el input, output y la configuración de retries, delays y timeouts [06:10]. Esto es particularmente útil cuando se conecta a proveedores de LLMs, que suelen tener latencia o inestabilidad durante lanzamientos de modelos nuevos.
¿Cómo optimizar la latencia con placement e HyperDrive?
El parámetro placement del worker permite controlar dónde se ejecuta. La opción smart ubica el worker en la posición más cercana al origen de forma automática, mientras que regional permite especificar una región exacta como Virginia [07:25]. Una anécdota real: un servicio que tardaba entre cuatro y cinco segundos pasó a 400 milisegundos con este único ajuste.
HyperDrive es un servicio complementario que actúa como pool de conexiones para bases de datos legacy, administrando el acceso de forma óptima y enrutando hacia la ubicación más conveniente [08:10].
Relacionado con esto, los Workers VPC utilizan túneles de Cloudflare para establecer conexiones directas entre el worker y servidores privados en cualquier proveedor [08:50]. Los túneles se configuran en el servidor origen con alta disponibilidad y permiten acceder a APIs privadas, conectar HyperDrive y cubrir múltiples casos de uso con una sola pieza de infraestructura.
Actualmente, la latencia observada ronda los 144 a 239 milisegundos, un tiempo razonable considerando las operaciones involucradas. Un worker puro alcanza entre 50 y 120 milisegundos dependiendo del edge de salida [09:30].
Si quieres practicar, hay un reto pendiente: la URL del avatar está rota y no carga nada. Existen diferentes soluciones posibles. Comparte en los comentarios cuál fue la que te funcionó.
