Temporal en Kubernetes: por qué realmente lo uso (y la vez que me salvó)

Si un workflow de IA falla a mitad de camino, quiero poder reanudarlo, no reconstruirlo.

He usado Temporal en proyectos personales y experimentos. No tengo un cluster enorme en producción, pero la propuesta de valor me parece clara: ejecución durable de workflows multi-paso.

Qué resuelve Temporal

Los workflows de IA típicamente combinan:

• Llamadas a APIs externas.
• Procesamiento de documentos.
• Esperas por aprobación humana.
• Escritura en varios sistemas.

Si cualquiera de esos pasos falla, un script normal puede dejar el sistema en un estado inconsistente. Temporal guarda el historial de eventos y reproduce el estado desde el último punto seguro.

Componentes que importan

• Servidor: Frontend, History, Matching, Worker internos.
• Persistencia: PostgreSQL, MySQL o Cassandra.
• Visibilidad: Elasticsearch para buscar ejecuciones.
• Workers: tus procesos que ejecutan las activities.

La separación entre workflow y activity es clave. El workflow decide qué hacer. La activity hace el trabajo. El servidor se asegura de que el workflow progrese aunque los workers se reinicien.

Cuándo lo uso

• Workflows que duran más de unos minutos.
• Procesos con pasos de compensación.
• Cualquier cosa que no pueda perderse por un reinicio.
• Pipelines de IA que integran varios sistemas.

Cuándo no lo uso

Para tareas simples de minuto o menos, Temporal es overkill. Ahí prefiero n8n o un script con buena observabilidad.

Conclusión

Temporal no es para todo. Pero para workflows de IA stateful y de larga duración, su modelo de ejecución durable es difícil de igualar con colas o scripts tradicionales.

Si tu workflow tiene estado importante y duración variable, Temporal debería estar en tu radar.