La crisis del "Glue Code": por qué la orquestación distribuida de workflows es difícil

SchemaBridge Team · 2025-12-01 · Distributed Systems, Architecture, DevOps

Deja de malgastar tiempo de ingeniería en fontanería de APIs. Descubre por qué la orquestación distribuida de workflows es la clave para escalar sistemas fragmentados en 2026.

El cuello de botella de la arquitectura: un asesino silencioso de la productividad

Como desarrollador sénior o arquitecto, ya has vivido este ciclo: empiezas con una integración "sencilla", como sincronizar un pedido de Shopify con un ERP heredado. Escribes un script de 50 líneas, lo envuelves en una Lambda o un cron job y lo despliegas. Funciona el primer día. Funciona el décimo. Pero entonces el mundo cambia. La API de Shopify añade un rate limit. El ERP heredado sufre contención de bloqueos en la base de datos a las 2:00 de la madrugada. Un proveedor logístico externo cambia la estructura de su respuesta JSON.

Antes de que te des cuenta, tu "script rápido" se ha convertido en una pieza de infraestructura crítica. Pero no se construyó como infraestructura, sino como un script. Carece de un manejo de errores adecuado, no entiende el concepto de estado y no tiene resiliencia integrada. Cuando falla, lo hace en silencio o, peor aún, falla parcialmente, dejando tus datos en un estado corrupto cuya reparación manual lleva días.

Tres meses después, ese script de 50 líneas ha mutado en un monstruo de 5.000. Ahora gestiona reintentos (mal, con bucles infinitos), escribe logs en tres sitios distintos (uno de ellos lleno) y contiene bloques try-except anidados que ocultan los errores reales. Tienes 20 scripts así repartidos por tu infraestructura. Son el "Glue Code" de tu organización. Esto no es ingeniería; es fontanería reactiva.

Esta es la crisis del Glue Code. Es el asesino silencioso de la velocidad de ingeniería. Ya no construyes funcionalidades que muevan la aguja del negocio; construyes y mantienes "tuberías" frágiles que pierden datos, se atascan bajo carga y revientan a las 3:00 de la madrugada, disparando alertas que despiertan a tus mejores ingenieros. En un mundo de microservicios fragmentados y APIs SaaS sin fin, si no tienes una estrategia de orquestación duradera, estás construyendo una casa sobre cemento de fraguado rápido. Parece sólida durante una semana, pero las grietas son inevitables.

Las raíces históricas de la crisis: de CGI-BIN a la nube

Para entender por qué estamos en esta crisis, hay que mirar la historia de la integración de software. En los años 90 teníamos scripts CGI y Perl. Eran comandos pequeños y sin estado que transformaban una petición en una respuesta. Fueron el "Glue Code" original. Eran magníficos para su época, pero nunca se pensaron para manejar los recorridos de varios pasos y varios días de un negocio digital moderno. Eran herramientas de "dispara y olvida" en un mundo que aún no estaba siempre conectado ni globalmente interconectado.

En los 2000 pasamos a los ESB (Enterprise Service Buses): middleware masivo y pesado como Tibco o BizTalk. Eran potentes, pero increíblemente complejos y caros. Intentaban centralizarlo todo, lo que generó un cuello de botella de "arquitectos del bus". Cada cambio requería una reunión de comité. El bus se convirtió precisamente en lo que debía resolver: un punto único de fallo y una enorme fuente de fricción organizativa.

En los 2010 rechazamos el ESB en favor de los microservicios. Pasamos a APIs REST y scripts ligeros (Python, Go, Node.js). Creíamos que ganábamos libertad. Pero lo que hicimos en realidad fue mover la complejidad del "bus" al "espacio entre servicios". Sustituimos un único middleware pesado por miles de scripts diminutos y frágiles dispersos por todo el entorno. Hoy vivimos en un mundo en el que la complejidad es O(N^2) respecto al número de servicios. Hemos cambiado un cuello de botella centralizado por un caos descentralizado.

La psicología del script: por qué seguimos eligiendo caminos frágiles

¿Por qué seguimos escribiendo scripts? Incluso ingenieros sénior, que conocen las trampas de los sistemas distribuidos, recurren con frecuencia al "script rápido" en lugar del "orquestador duradero". La razón es psicológica.

1. La falacia de la "victoria rápida"

Cuando un stakeholder de negocio pide una nueva integración, la quiere "para ayer". Un script parece rápido. Lo escribes en una hora. Te sientes productivo. "Marcas la casilla". Pero es una productividad falsa. Estás pidiendo un préstamo a alto interés contra tu capacidad futura. Las horas que ahorras hoy las pagas multiplicadas el mes que viene, depurando un fallo parcial en producción. El script es una droga adictiva para los responsables de ingeniería que valoran las métricas a corto plazo por encima de la estabilidad a largo plazo.

2. El efecto Dunning-Kruger de los sistemas distribuidos

Muchos desarrolladores creen que "los reintentos son fáciles". Piensan que basta con envolver una llamada a una API en un bucle while con un temporizador de espera. Todavía no han vivido la tormenta de reintentos, la identidad huérfana ni la corrupción de estado que se producen en un entorno de producción real. Están en el "pico de expectativas infladas" respecto a su propia capacidad para gestionar fallos. Hasta la primera gran caída a las 3:00 de la madrugada no se dan cuenta de que el estado distribuido es un problema que exige soluciones a nivel de infraestructura.

3. La falta de una unidad de trabajo mejor

Hasta hace poco carecíamos de una unidad de trabajo estándar para la orquestación. Teníamos "funciones" y "servicios", pero no "recorridos". SchemaBridge introduce el Durable Workflow como esa unidad de trabajo. Permite expresar un recorrido de varios pasos como una sola entidad cuyo estado se persiste, de modo que una caída o un reinicio de un worker recupera el paso en curso en lugar de perder el recorrido.

Anatomía del fallo: por qué los "scripts" no escalan

Un script que funciona para 10 usuarios falla con 10.000 por tres razones principales inherentes a la naturaleza de los sistemas distribuidos. No podemos resolver estos problemas solo con "mejor código"; tenemos que resolverlos con infraestructura.

1. El problema del éxito parcial: el estado "a medio hacer"

En un sistema distribuido, el éxito no es binario. Supongamos que tu script realiza tres pasos: 1) Cobrar al cliente vía Stripe. 2) Actualizar la base de datos interna de inventario. 3) Enviar un correo de confirmación vía SendGrid. ¿Qué pasa si el proceso se cae después del paso 1?

Al cliente se le ha cobrado, pero tu inventario sigue marcado como "En stock" y el usuario no tiene recibo. Para resolverlo con código puro, tienes que escribir a mano complejos patrones Saga: en esencia, un mini-orquestador para cada script. Tienes que comprobar si el cobro se produjo, comprobar el estado del inventario y gestionar los rollbacks. Este boilerplate acaba dominando tu tiempo de desarrollo, y aun así a veces te equivocas, porque el estado distribuido es difícil.

2. La brecha de idempotencia: el peligro de los reintentos

La conectividad es inestable. Un script captura un timeout de una API y reintenta. Pero ¿y si la API en realidad tuvo éxito y lo único que expiró fue la respuesta? Sin idempotencia, tu reintento provoca un doble cobro o un envío duplicado. La mayoría de los desarrolladores de "Glue Code" lo ignoran hasta la primera vez que se le cobran a un cliente 5.000 $ en lugar de 500 $.

Añadir claves de idempotencia a cada llamada a API en decenas de servicios es una carga logística que pocos equipos gestionan con constancia. Con 100 integraciones tienes 100 sitios donde olvidar una clave. Un motor de orquestación puede quitarte parte de esta carga, pero conviene ser preciso sobre qué parte. SchemaBridge deduplica los disparadores entrantes (mediante un hash del contenido del payload o mediante una clave que tú proporcionas), de modo que un proveedor que reenvía el mismo webhook no inicia el mismo recorrido dos veces. Los efectos secundarios salientes, en cambio, se ejecutan at-least-once: un paso puede volver a ejecutarse tras una caída. Para un destino no idempotente, pasa en la propia llamada una clave de idempotencia derivada de un campo de negocio estable (un ID de pedido, un payment intent).

Las ocho falacias: una base para el fallo

Para entender de verdad por qué falla el Glue Code, debemos volver a las ocho falacias de la computación distribuida, formuladas por primera vez por Peter Deutsch y otros en Sun Microsystems. Son las suposiciones falsas que todo desarrollador hace cuando empieza a escribir código en red. Son los "falsos paraísos" de la ingeniería:

1. La red es fiable: No lo es. Se pierden paquetes, los routers se reinician y los cables se cortan. En un entorno cloud, a escala puedes esperar un fallo de red intermitente cada día.

2. La latencia es cero: No lo es. Incluso las redes de fibra globales más rápidas introducen milisegundos de retardo que se acumulan a lo largo de miles de llamadas. Este retardo es irregular e impredecible, y provoca condiciones de carrera que desaparecen cuando intentas depurarlas en local.

3. El ancho de banda es infinito: No lo es. Los payloads grandes atascarán tus tuberías y provocarán timeouts. Los proveedores cloud tienen además cuotas de ancho de banda estrictas que limitarán tu "Glue Code" sin previo aviso.

4. La red es segura: No lo es. Los ataques man-in-the-middle, el envenenamiento de DNS y los tokens filtrados son amenazas constantes. Tu script de "Glue Code" es un objetivo prioritario para el robo de credenciales si no está bien aislado.

5. La topología no cambia: Sí cambia. Los balanceadores de carga se desplazan, los nodos mueren y las direcciones IP se reciclan. La "IP hardcodeada" de tu script es una bomba de relojería.

6. Hay un solo administrador: No lo hay. Estás a merced de AWS, Cloudflare y cada proveedor SaaS de tu stack. Cuando cambian su API, tu script es la primera víctima.

7. El coste de transporte es cero: No lo es. Serializar y deserializar JSON a escala tiene un coste real de CPU y memoria. Un script puede pasar una parte sorprendente de su tiempo simplemente analizando y volviendo a analizar payloads en json.loads().

8. La red es homogénea: No lo es. Tu stack es una mezcla de Linux, Windows, JVM, Node y servicios SOAP heredados. Esperar un comportamiento fijo en este panorama es un espejismo.

Análisis técnico en profundidad: event sourcing y escalabilidad de la persistencia

Una de las partes más difíciles de construir un motor de orquestación duradero es gestionar la persistencia del estado. Cuando un gran volumen de workflows se ejecuta a la vez y cada uno realiza muchos pasos, la carga de escritura sobre la capa de persistencia crece rápidamente.

El cuello de botella de la base de datos

Un esquema ingenuo —una fila workflow_history ancha y mutable que se reescribe con el estado completo en cada paso— acabará cediendo bajo esta carga, porque la contención de índices y bloqueos en las filas calientes se convierte en el principal cuello de botella. SchemaBridge divide el problema en dos sobre PostgreSQL: un registro pequeño de estado actual que cambia y un historial que solo crece.

1. Filas de estado pequeñas y protegidas: El estado actual de cada ejecución y de cada paso vive en filas de estado compactas que se actualizan con escrituras condicionales de tipo compare-and-set (un paso solo pasa de DISPATCHED a EXECUTING si nadie lo ha reclamado antes). Los payloads grandes se mantienen totalmente fuera de estas filas y se descargan en un almacén de objetos SeaweedFS (compatible con S3), y Valkey Streams se encarga de entregar el trabajo entre etapas.

2. Trazas de ejecución append-only: Cada paso añade además un registro de traza inmutable, lo que te proporciona un rastro paso a paso de la ejecución. La tabla de trazas está particionada por mes, de modo que las particiones antiguas se eliminan de forma barata cuando superan el periodo de retención, en lugar de borrarse fila a fila.

3. Recuperación ante caídas sin rehidratación: Como el estado actual es duradero, un worker nunca tiene que reconstruirlo en memoria. Si un worker muere a mitad de un paso, la reclamación del paso caduca y otro worker lo recupera y lo vuelve a ejecutar. Eso es ejecución at-least-once, y precisamente por eso importa el consejo anterior sobre idempotencia saliente.

La brecha de gobernanza: ¿de quién es la fontanería?

Más allá de los retos técnicos hay uno cultural: la brecha de gobernanza. En una arquitectura de microservicios tradicional, la propiedad está compartimentada. El equipo del "Product Service" es dueño de la base de datos de productos. El equipo del "Shipping Service" es dueño de la integración con FedEx.

Pero ¿de quién es el puente entre ellos?

Normalmente, de nadie. El script de "Glue Code" lo escribe un desarrollador que necesita un arreglo rápido y luego se abandona. Cuando se rompe, el equipo de Product culpa al de Shipping, y el de Shipping culpa al proveedor de la API. No hay una "fuente de verdad" central sobre cómo están conectados realmente los procesos de negocio.

SchemaBridge lo resuelve convirtiendo la integración en un activo global.

La metáfora biológica: el software como sistema nervioso

Avanzamos hacia un mundo en el que el software ya no es una colección de herramientas estáticas, sino un sistema nervioso vivo. En un sistema nervioso biológico, una señal viaja del dedo (el sensor) al cerebro (la lógica) y vuelve al músculo (la acción). Si parte del camino se bloquea, el sistema se adapta. Tiene reflejos. Tiene memoria.

La orquestación duradera es el sistema nervioso de la empresa. Permite que tus servicios fragmentados se comporten como un único organismo cohesionado.

1. Los reflejos: Los reintentos automáticos con backoff absorben pequeños "dolores" (un 5xx transitorio, una respuesta de rate limit, una conexión caída en una llamada HTTP) sin implicar al cerebro (el desarrollador).

2. La memoria: El estado de ejecución se persiste, así que tras un reinicio —incluso de todo el clúster— los pasos en curso se recuperan y se vuelven a ejecutar en lugar de olvidarse. Como esa reejecución es at-least-once, los efectos secundarios siguen necesitando ser idempotentes en el destino.

3. La consciencia: La observabilidad visual (consulta La brecha de observabilidad) te permite ver cada ejecución en tiempo real: qué paso se está ejecutando, cuál ha fallado y el payload que entró y salió.

Escenario ilustrativo: el colapso silencioso de la conciliación

Para entender la gravedad de la crisis, piensa en una fintech que concilia las transacciones diarias entre su libro mayor interno y las APIs de varios bancos asociados mediante un gran conjunto de scripts de Python.

La caída

Imagina que un viernes un banco asociado cambia el esquema de autenticación de su API de conciliación. El script de Python no se cae; simplemente recibe un rechazo, captura la excepción y marca "en silencio" la conciliación del día como "Pending". Como no hay un panel visual, el fallo pasa desapercibido durante días.

Cuando alguien por fin lo mira, se ha acumulado una discrepancia grande y creciente entre el libro mayor y los bancos. Se involucra a los auditores, se avisa a la dirección y el equipo de ingeniería tiene que pasar días reconstruyendo a mano la cronología de la conciliación. El script funcionaba perfectamente en el "happy path", pero no tenía ninguna capacidad de "autorreparación" ni ninguna "verdad visual".

La alternativa con SchemaBridge

Ahora imagina la misma lógica de conciliación ejecutándose en SchemaBridge. Cuando llega un cambio de autenticación similar, el vertex Gateway (la llamada HTTP saliente al banco) falla, y la ejecución se pone en rojo en el monitor con la respuesta rechazada adjunta al paso fallido. SchemaBridge no avisa a nadie por sí solo, pero el equipo puede hacer que este caso no pase desapercibido: con clientErrorMode del gateway configurado como complete, una llamada rechazada (4xx) se convierte en un resultado invalid_input sobre el que se puede enrutar, directamente hacia un paso de notificación en Slack. En cualquier caso, el fallo es visible el mismo día y no días después. Corrigen la credencial, pulsan Retry (Reintentar) en el paso fallido y la conciliación se reanuda desde donde se detuvo en lugar de reconstruirse a mano.

Recursos recomendados para una orquestación sin errores

Si quieres dominar el arte de la ejecución duradera, te recomendamos esta lista de lecturas seleccionadas:

Conclusión: el nuevo mandato del arquitecto

La crisis del Glue Code es el síntoma de una transición. Pasamos de un mundo de "silos y scripts" a un mundo de "ecosistemas conectados". En este nuevo mundo, las conexiones entre tus servicios son tan importantes como los propios servicios.

Tu mandato como arquitecto ya no es solo construir servicios fiables, sino construir conexiones fiables. El Glue Code es la antítesis de la fiabilidad. Es un parche temporal que inevitablemente se convierte en una carga permanente. Es hora de dejar de construir tuberías frágiles y empezar a construir un sistema nervioso digital.

Al adoptar un motor de orquestación duradero como SchemaBridge, recuperas el futuro de tu ingeniería. Construyes sistemas que conocen su estado, que resisten los fallos y que son visibles para toda la organización. Así es como recuperas tu velocidad y construyes sistemas que perduran.

Este artículo forma parte de nuestra serie Building the Bridge. Consulta también: Diseñar para la velocidad: argumentos a favor de la ingesta de eventos sin esquema, el enfoque de late binding para la ingesta de eventos.

Explorar