Orquestación de workflows: AWS Step Functions

En la orquestación hay un orquestador que conoce el proceso completo. Llama al servicio de pagos, espera su respuesta, decide el siguiente paso y, si algo falla, ejecuta las compensaciones (por ejemplo, el reembolso). Los servicios no se conocen entre sí: solo responden al orquestador.

La gran ventaja es la visibilidad: en un único sitio puedes ver en qué paso está cada pedido, por qué falló y qué se reintentó. Cambiar el orden de los pasos es cambiar una definición, no tocar varios servicios.

En la coreografía nadie dirige. El servicio de pedidos publica «pedido creado»; el de pagos lo escucha, cobra y publica «pago cobrado»; el almacén escucha ese evento y prepara el envío. Es la mensajería pub/sub que viste en la lección anterior aplicada a un proceso de negocio.

Los servicios quedan muy desacoplados: añadir uno nuevo que reaccione a «pago cobrado» no obliga a tocar a nadie. El precio es que el proceso completo no está escrito en ningún sitio: hay que reconstruirlo siguiendo eventos, algo que verás con las trazas distribuidas en el módulo de observabilidad.

Step Functions es el servicio de orquestación de AWS. Defines una máquina de estados en Amazon States Language (ASL), un formato JSON en el que cada paso es un estado con un tipo, y AWS se encarga de ejecutarla, guardar el progreso, reintentar y registrar el historial. La consola la dibuja como un diagrama y Workflow Studio te deja editarla visualmente.

Cada ejecución recibe un JSON de entrada que pasa de estado en estado. Los estados Task pueden invocar funciones Lambda o llamar directamente a muchos servicios de AWS (DynamoDB, SQS, SNS…) sin escribir código intermedio. Para elegir y transformar datos se usan expresiones JSONPath como $.pedidoId; en las versiones recientes también puedes usar JSONata y variables.

Un Task ejecuta una unidad de trabajo indicada en Resource: una función Lambda, una llamada directa a un servicio de AWS o incluso una API HTTP externa. Su resultado se combina con la entrada y pasa al estado siguiente.

Además de la llamada simple, admite patrones para esperar trabajos largos: con .sync espera a que termine, por ejemplo, un trabajo de AWS Batch, y con .waitForTaskToken se queda en pausa hasta que alguien devuelva un token, útil para una aprobación humana.

Un Choice evalúa sus reglas en orden y sigue la primera que se cumple; si ninguna se cumple, va a Default. Las reglas comparan valores de la entrada: números, textos, booleanos o fechas, y se pueden combinar con And, Or y Not.

Un Parallel contiene varias ramas, cada una con su propia mini máquina de estados. Todas reciben la misma entrada y se ejecutan simultáneamente; la salida es una lista con el resultado de cada rama, en el mismo orden.

Si una rama falla y nadie captura el error, el Parallel entero falla y se detienen las demás.

Un Map recorre una lista de la entrada y ejecuta para cada elemento los estados de su ItemProcessor, con MaxConcurrency para limitar cuántos van a la vez. Es el forEach de Step Functions.

En modo inline, las iteraciones viven dentro de la misma ejecución. En modo distributed, cada iteración es una ejecución hija, pensada para procesar grandes volúmenes, como los millones de líneas de un archivo en S3.

Un Wait detiene la ejecución durante unos segundos (Seconds) o hasta un instante concreto (Timestamp), que también puede venir de la entrada con SecondsPath o TimestampPath. Mientras espera no hay ningún proceso tuyo encendido.

Pass no hace trabajo: pasa su entrada a la salida y, opcionalmente, añade datos fijos. Sirve para valores por defecto o para dibujar un flujo antes de implementar sus pasos. Succeed termina la ejecución con éxito y Fail la termina con un error y una causa que quedan registrados en el historial.

Un workflow Standard puede durar hasta un año y ejecuta cada paso exactamente una vez, salvo que tú configures reintentos. Guarda el historial completo de cada ejecución, que puedes revisar en la consola paso a paso. Se cobra por cada transición entre estados.

Es el tipo que admite todos los patrones de integración, incluidas las esperas a un trabajo largo (.sync) y a un token de callback (.waitForTaskToken).

Un workflow Express dura como máximo cinco minutos y está pensado para muchísimas ejecuciones por segundo. Su garantía es más débil: al menos una vez si lo lanzas de forma asíncrona y como mucho una vez si es síncrono. Se cobra por número de ejecuciones, duración y memoria, y el historial se envía a CloudWatch Logs si lo activas.

El campo Retry de un Task, Parallel o Map es una lista de reglas. Cada una indica qué errores cubre (ErrorEquals), cuánto esperar antes del primer reintento (IntervalSeconds, 1 por defecto), cuántas veces intentarlo (MaxAttempts, 3 por defecto) y el BackoffRate, el factor por el que se multiplica la espera tras cada intento (2 por defecto).

Con IntervalSeconds: 2 y BackoffRate: 2, las esperas son 2, 4 y 8 segundos: es el backoff exponencial, que da tiempo a recuperarse al servicio caído. Las versiones recientes también admiten MaxDelaySeconds para poner un tope y JitterStrategy para añadir variación aleatoria.

El campo Catch indica a qué estado saltar cuando un error no se ha resuelto con reintentos. Se evalúa después de agotar el Retry. Con ResultPath decides dónde guardar la información del error sin perder la entrada original, para que el estado de recuperación sepa qué pedido estaba en juego.

Así se implementan las compensaciones: si falla el envío después de cobrar, el Catch lleva a un estado que reembolsa y otro que avisa al cliente.