Respuesta a la pregunta.
La arquitectura se centra en el patrón de Ejecución Duradera, separando la computación efímera del estado duradero a través de un plano de control basado en eventos. En su núcleo, las definiciones de flujo de trabajo se ejecutan como máquinas de estado deterministas donde cada transición de estado se persiste como un evento inmutable en Apache Kafka (registro de escritura anticipada) antes de la confirmación, lo que permite la reproducción determinista durante fallos. La capa de computación utiliza AWS Lambda o Azure Functions organizadas en VPCs e IAM específicos de inquilinos, asegurando aislamiento mientras aprovechan grupos de conservación de concurrencia provisionados para mitigar los inicios en frío. Para la semántica exactamente una vez entre regiones, el sistema emplea CockroachDB con aislamiento serializable predeterminado para almacenar el estado del flujo de trabajo, utilizando el consenso Raft para la consistencia entre regiones sin requerir un servicio coordinador separado. La correlación de eventos logra latencias de subsegundos a través de un enfoque por capas: los clústeres de Redis con indexación RedisJSON manejan la coincidencia de eventos calientes en memoria, mientras que Elasticsearch sirve como almacenamiento en frío para consultas de correlación históricas, con Cloudflare Workers proporcionando almacenamiento en búfer a nivel de borde de eventos para absorber picos de tráfico.
Situación de la vida real
Durante el Black Friday 2023, SwiftCart (una plataforma de comercio electrónico global) enfrentó fallas catastróficas en su implementación de Step Functions heredada mientras procesaba 50M de flujos de trabajo de entrega concurrentes que duraban de 3 a 7 días cada uno. Cuando us-east-1 experimentó un corte regional, el failover a us-west-2 resultó en 12,000 envíos duplicados porque la reconciliación del estado del flujo de trabajo dependía de la consistencia eventual de DynamoDB con ventanas de TTL de 5 minutos. Al mismo tiempo, los eventos de webhook de transportistas enfrentaron retrasos de correlación de 30 segundos, rompiendo las promesas de seguimiento en tiempo real a los clientes y incurriendo en $2M en penalizaciones por SLA.
Solución A: Orquestador basado en Kubernetes con Airflow en EKS
Este enfoque prometía control total y herramientas maduras a través de Apache Airflow ejecutándose en Amazon EKS con PostgreSQL como la base de datos de metadatos. Los pros incluían extensos ecosistemas de complementos y entornos de desarrollo locales sencillos. Sin embargo, los contras resultaron fatales: la latencia de programación de pods promedió 45 segundos, violando el requisito de escala a cero de que los flujos de trabajo inactivos debían incurrir en costos computacionales cercanos a cero. Además, mantener la replicación síncrona de PostgreSQL entre regiones añadía 200 ms a cada transición de estado de tarea, y la falta de una semántica exactamente una vez incorporaba un bloqueo complejo a nivel de aplicación que frecuentemente se interrumpía durante los failovers regionales.
Solución B: Coreografía impulsada por eventos pura utilizando Kafka y Lambda
Este enfoque nativo sin servidor utilizó Amazon MSK (Kafka) como la fuente de verdad con funciones de Lambda reaccionando a eventos sin un orquestador central. Los pros incluían una verdadera economía de pago por uso y una resiliencia natural a través de la persistencia basada en registros. Sin embargo, implementar la semántica exactamente una vez requería transacciones distribuidas que abarcan DynamoDB (para idempotencia) y Kafka, introduciendo latencias de más de 500 ms por operación. Además, reconstruir el estado del flujo de trabajo para procesos de larga duración (día 5 de un flujo de trabajo de 7 días) requería reproducir millones de eventos de archivos de S3, causando tiempos de recuperación que excedían los 10 minutos y haciendo imposible la depuración de "espagueti distribuido" cuando ocurrían fallos en medio de la secuencia.
Solución C: Plataforma de Ejecución Duradera con gestión de estado fragmentada
La arquitectura elegida implementó un plano de control inspirado en Temporal que separa el estado duradero (CockroachDB con tablas geo-particionadas) de los trabajadores efímeros de Lambda. El Hashing Consistente distribuyó fragmentos de flujo de trabajo a través de nodos de base de datos regionales, mientras que Redis Streams proporcionó almacenamiento en búfer de correlación de eventos de submilisegundos. Los pros incluían exactamente una vez nativa a través de las transacciones serializables de CockroachDB, reproducción determinista para depuración y verdadera escala a cero donde los flujos de trabajo inactivos residían únicamente en económicos instantáneas de S3. Los contras implicaban una complejidad operativa significativa en el mantenimiento de clústeres de etcd para el descubrimiento de servicios y la necesidad de un almacenamiento en caché sofisticado para prevenir oleadas durante escenarios de activación masiva.
Resultado
Al implementar la Solución C con colas SQS por inquilino y tiempos de visibilidad de 1 segundo, SwiftCart logró cero duplicación de flujos de trabajo durante el evento de Prime Day subsiguiente a pesar de un corte de 45 minutos en us-west-2. La latencia de correlación de eventos p95 bajó a 400 ms a través de la caché de borde de Redis. Los costos de infraestructura disminuyeron en un 70% en comparación con el enfoque siempre activo de EKS, con un 85% de los flujos de trabajo existiendo únicamente como instantáneas de estado comprimidas en S3 durante períodos de espera inactivos, resultando en un ahorro anual de $1.4M.
Lo que los candidatos a menudo pasan por alto
¿Cómo evitas la divergencia del estado del flujo de trabajo cuando ambas regiones procesan simultáneamente eventos durante una partición de red?
La mayoría de los candidatos sugieren incorrectamente las semánticas de última escritura gana en DynamoDB o Cassandra, lo que falla para la orquestación de flujos de trabajo porque las operaciones comerciales son no conmutativas (por ejemplo, "cancelar pedido" versus "enviar pedido" no se pueden reconciliar solo por marca temporal). La implementación correcta utiliza Relojes Vectoriales o Vectores de Versiones Marcadas incrustados dentro de los metadatos del estado del flujo de trabajo. Cuando la partición de la red se repara, el sistema detecta ramas simultáneas mediante la comparación de vectores de versión y aplica funciones de fusión específicas del dominio. Para conflictos irreconciliables (como la cancelación y el envío simultáneos), la arquitectura implementa un patrón de compensación de saga donde la operación posterior desencadena un retroceso de la acción anterior con un registro de auditoría completo. Alternativamente, aprovechar el aislamiento serializable predeterminado de CockroachDB previene totalmente la divergencia al rechazar escrituras conflictivas durante la partición, forzando bucles de reintento explícitos con espera exponencial en lugar de permitir la corrupción silenciosa de datos.
¿Cómo manejas la versionado del código del flujo de trabajo cuando un flujo de trabajo de 7 días iniciado con v1.0 debe completarse después de que hayas desplegado v2.0 con semánticas de actividad alteradas?
Los candidatos a menudo pasan por alto el requisito de Reproducción Determinista fundamental para la ejecución duradera. Simplemente actualizar el código de la función Lambda interrumpe los flujos de trabajo en curso porque la lógica de reproducción (utilizada para reconstruir el estado después de fallas) diverge del camino de ejecución original, causando excepciones no deterministas. La solución implementa una Versionado de Flujo de Trabajo explícita a través de marcadores de origen de eventos. Al desplegar v2.0, los trabajadores deben admitir simultáneamente tanto las implementaciones de actividad v1.0 como v2.0 dentro de WebAssembly sandboxes o contenedores Docker separados. Los registros de estado del flujo de trabajo registran qué versión de código ejecutó cada actividad histórica; durante la reproducción, el trabajador carga el sandbox de la versión histórica específica para garantizar la reejecución determinista de pasos anteriores, mientras que los nuevos flujos de trabajo utilizan v2.0. Después de la duración máxima del flujo de trabajo (7 días más un margen de seguridad de 24 horas), el código v1.0 puede ser desmantelado. Esto requiere mantener firmas de actividad que sean compatibles con versiones anteriores indefinidamente o emplear Pruebas de Contrato Pact para verificar la equivalencia de comportamiento entre versiones.
¿Cómo te proteges contra flujos de trabajo "pastilla envenenada" que contienen bucles infinitos o fugas de memoria en el código del usuario sin romper las garantías exactamente una vez para flujos de trabajo saludables?
Las simples Colas de Mensajes Muertos (DLQ) en realidad violan las semánticas exactamente una vez porque mover un mensaje a una DLQ requiere reconocer el mensaje original, lo que arriesga la pérdida de mensajes si la escritura en la DLQ falla o el consumidor se bloquea a mitad de operación. La solución robusta emplea Seguimiento de Progreso con puntos de control idempotentes. Los trabajadores envían señales cada 30 segundos, escribiendo tokens de progreso en etcd o CockroachDB usando operaciones de comparar e intercambiar. Si un trabajador se bloquea tres veces consecutivas en la misma tarea de flujo de trabajo (detectado mediante un contador de intentos de ejecución almacenado en la base de datos), la tarea se marca como "envenenada" pero permanece en la cola con un retraso de visibilidad que aumenta exponencialmente (1 minuto, 5 minutos, 30 minutos). Un grupo de trabajadores "quirúrgicos" separados con observabilidad mejorada, límites de memoria y detallado trazado de OpenTelemetry intenta la ejecución. Solo después de 24 horas de fallas persistentes el flujo de trabajo pasa a un estado "suspendido" que requiere intervención manual del operador, preservando invariable los exactamente una vez ya que todas las transiciones de estado utilizan marcas de tiempo MVCC en CockroachDB para operaciones atómicas de comparar e intercambiar.