Cada capítulo anterior construyó bien una API. Los sistemas reales no se paran en una. Webplo ejecuta api-server como concentrador delante de una docena de servicios hoja: un alojamiento de repositorios, un aprovisionador, un CDN, un generador de contenido con IA, un servicio de licencias, una pasarela de pagos. Una sola acción de un comerciante —alguien pulsando «crea mi sitio»— no toca uno de ellos. Toca casi todos, en orden, sobre una red que tira llamadas, mata procesos worker a mitad de petición y nunca pide permiso antes de hacer ninguna de las dos cosas.
Este capítulo cubre qué cambia cuando «la petición» se convierte en «un flujo de trabajo que abarca una docena de servicios»: encadenar trabajo multipaso para que un fallo a mitad sea recuperable en lugar de catastrófico, nombrar los recursos que ese flujo crea para que un reintento converja en uno solo en lugar de filtrar otro, barrer en busca del trabajo que se atasca sin levantar nunca una excepción, y poner la única pieza de resiliencia que toda integración necesita —reintento y espera— en exactamente un sitio en lugar de reinventarla hoja a hoja.
Un flujo de trabajo que sólo termina cuando no falla nada no es un flujo de trabajo. Es un incidente esperando su segundo intento.
Una peticion, una docena de servicios, ninguno promete «ahora»
El capítulo 4 ya puso un número a esto: una sola acción de un comerciante puede tocar tres servicios antes de terminar. Aprovisionar un sitio nuevo es la misma forma, estirada más: crear un repositorio, levantar el alojamiento, configurar un inquilino de CDN, generar contenido, desplegar, y sólo entonces decirle al comerciante que está listo.
merchant asks api-server to provision a site
↓
create the repository
↓
in parallel: CDN tenant · content generation · hosting setup
↓
deploy
↓
mark provisioning complete
El capítulo 7 ya te enseñó el código de esto. Lo que ese capítulo no subrayó es qué es realmente cada paso. RepositoryCreateJob no es lógica de negocio que casualmente corre en una cola: es una envoltura fina alrededor de una llamada HTTP a un servicio que no es api-server, que no comparte su base de datos y que puede fallar de formas que la suite de pruebas de api-server nunca ha visto. Bus::chain() garantiza que los pasos corren en orden. No dice nada sobre qué pasa cuando el paso tres, reintentado porque un worker murió a mitad de intento, llama a un servicio hoja por segunda vez.
Ese es el tema real de este capítulo. No «cómo encolas trabajo» —eso lo respondió el capítulo 7— sino «cómo encolas trabajo que se estira fuera de tu propio proceso, y sobrevives al hecho de que lo que hay al otro lado no sabe ni le importa que estés reintentando».