A crise do "Glue Code": por que a orquestração distribuída de workflows é difícil

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

Pare de desperdiçar tempo de engenharia com encanamento de APIs. Entenda por que a orquestração distribuída de workflows é a chave para escalar sistemas fragmentados em 2026.

O gargalo da arquitetura: um assassino silencioso da produtividade

Como desenvolvedor sênior ou arquiteto, você já viveu este ciclo: começa com uma integração "simples" — sincronizar um pedido da Shopify com um ERP legado. Escreve um script de 50 linhas, coloca-o em uma Lambda ou em um cron job e publica. Funciona no primeiro dia. Funciona no décimo. Mas então o mundo muda. A API da Shopify adiciona um rate limit. O ERP legado sofre contenção de locks no banco de dados às 2h da manhã. Um provedor de frete terceirizado muda a estrutura da sua resposta JSON.

Quando você percebe, seu "script rápido" virou uma peça de infraestrutura crítica. Mas ele não foi construído como infraestrutura; foi construído como um script. Falta tratamento de erros adequado, ele não entende o conceito de estado e não tem resiliência embutida. Quando falha, falha em silêncio — ou, pior, falha parcialmente, deixando seus dados em um estado corrompido que leva dias de esforço manual para corrigir.

Três meses depois, aquele script de 50 linhas se transformou em um monstro de 5.000. Agora ele faz retries (mal, com loops infinitos), grava logs em três lugares diferentes (um deles cheio) e contém blocos try-except aninhados que escondem os erros reais. Você tem 20 scripts assim rodando pela sua infraestrutura. Eles são o "Glue Code" da sua organização. Isso não é engenharia; é encanamento reativo.

Esta é a crise do Glue Code. É o assassino silencioso da velocidade de engenharia. Você não está mais construindo funcionalidades que fazem diferença para o negócio; está construindo e mantendo "canos" frágeis que vazam dados, entopem sob carga e estouram às 3h da manhã, disparando alertas que acordam seus melhores engenheiros. Em um mundo de microsserviços fragmentados e APIs SaaS sem fim, se você não tem uma estratégia de orquestração durável, está basicamente construindo uma casa sobre cimento de secagem rápida. Parece sólida por uma semana, mas as rachaduras são inevitáveis.

As raízes históricas da crise: do CGI-BIN à nuvem

Para entender por que estamos nesta crise, precisamos olhar para a história da integração de software. Nos anos 1990, tínhamos scripts CGI e Perl. Eram comandos pequenos e sem estado que transformavam uma requisição em uma resposta. Foram o "Glue Code" original. Eram ótimos para a sua época, mas nunca foram pensados para lidar com as jornadas de várias etapas e vários dias de um negócio digital moderno. Eram ferramentas "dispare e esqueça" em um mundo que ainda não estava sempre online e conectado globalmente.

Nos anos 2000, migramos para os ESBs (Enterprise Service Buses) — middlewares enormes e pesados como Tibco ou BizTalk. Eram poderosos, mas incrivelmente complexos e caros. Tentavam centralizar tudo, o que criou um gargalo de "arquitetos do barramento". Toda mudança exigia uma reunião de comitê. O barramento virou exatamente aquilo que deveria resolver: um ponto único de falha e uma enorme fonte de atrito organizacional.

Nos anos 2010, rejeitamos o ESB em favor dos microsserviços. Passamos para APIs REST e scripts leves (Python, Go, Node.js). Achávamos que estávamos ganhando liberdade. Mas o que fizemos de fato foi mover a complexidade do "barramento" para o "espaço entre os serviços". Trocamos um único middleware pesado por milhares de scripts minúsculos e frágeis espalhados pelo ambiente. Hoje vivemos em um mundo em que a complexidade é O(N^2) em relação ao número de serviços. Trocamos um gargalo centralizado por um caos descentralizado.

A psicologia do script: por que continuamos escolhendo caminhos frágeis

Por que continuamos escrevendo scripts? Até engenheiros seniores, que conhecem as armadilhas de sistemas distribuídos, frequentemente recorrem ao "script rápido" em vez do "orquestrador durável". O motivo é psicológico.

1. A falácia da "vitória rápida"

Quando um stakeholder de negócio pede uma nova integração, ele a quer "para ontem". Um script parece rápido. Você o escreve em uma hora. Sente-se produtivo. "Marca o checkbox". Mas essa é uma produtividade falsa. Você está fazendo um empréstimo a juros altos contra sua capacidade futura. As horas que você economiza hoje voltam multiplicadas no mês que vem, gastas depurando uma falha parcial em produção. O script é uma droga viciante para gestores de engenharia que valorizam métricas de curto prazo acima da estabilidade de longo prazo.

2. O efeito Dunning-Kruger dos sistemas distribuídos

Muitos desenvolvedores acreditam que "retries são fáceis". Acham que basta envolver uma chamada de API em um loop while com um timer de espera. Ainda não viveram a tempestade de retries, a identidade órfã ou a corrupção de estado que acontecem em um ambiente de produção real. Estão no "pico das expectativas infladas" em relação à própria capacidade de lidar com falhas. Só na primeira grande queda às 3h da manhã percebem que estado distribuído é um problema que exige soluções em nível de infraestrutura.

3. A falta de uma unidade de trabalho melhor

Até pouco tempo atrás, não tínhamos uma unidade de trabalho padrão para orquestração. Tínhamos "funções" e "serviços", mas não "jornadas". O SchemaBridge introduz o Durable Workflow como essa unidade de trabalho. Ele permite expressar uma jornada de várias etapas como uma única entidade cujo estado é persistido, de modo que uma queda ou reinício de um worker retoma a etapa em andamento em vez de perder a jornada.

A anatomia da falha: por que "scripts" não escalam

Um script que funciona para 10 usuários falha com 10.000 por três motivos principais, inerentes à natureza dos sistemas distribuídos. Não conseguimos resolver esses problemas apenas com "código melhor"; precisamos resolvê-los com infraestrutura.

1. O problema do sucesso parcial: o estado "meio pronto"

Em um sistema distribuído, sucesso não é binário. Suponha que seu script execute três etapas: 1) Cobrar o cliente via Stripe. 2) Atualizar o banco de dados interno de estoque. 3) Enviar um e-mail de confirmação via SendGrid. O que acontece se o processo cair depois da etapa 1?

O cliente foi cobrado, mas seu estoque continua marcado como "Em estoque", e o usuário não recebeu nenhum recibo. Para resolver isso com código puro, você precisa escrever à mão complexos padrões Saga — basicamente um mini-orquestrador para cada script. É preciso verificar se a cobrança aconteceu, conferir o status do estoque e tratar rollbacks. Esse boilerplate acaba dominando seu tempo de desenvolvimento, e você ainda erra de vez em quando, porque estado distribuído é difícil.

2. A lacuna de idempotência: o perigo dos retries

A conectividade é instável. Um script captura um timeout de uma API e tenta de novo. Mas e se a API na verdade teve sucesso, e só a resposta expirou? Sem idempotência, seu retry resulta em cobrança duplicada ou em um envio duplicado. A maioria dos desenvolvedores de "Glue Code" ignora isso até a primeira vez que um cliente é cobrado em US$ 5.000 em vez de US$ 500.

Adicionar chaves de idempotência a cada chamada de API em dezenas de serviços é um fardo logístico que poucos times conseguem manter de forma consistente. Com 100 integrações, você tem 100 lugares para esquecer uma chave. Um motor de orquestração pode tirar parte disso das suas costas, mas seja preciso sobre qual parte. O SchemaBridge deduplica gatilhos de entrada (por um hash do conteúdo do payload ou por uma chave que você fornece), de modo que um provedor que reenvia o mesmo webhook não inicia a mesma jornada duas vezes. Já os efeitos colaterais de saída rodam at-least-once: uma etapa pode ser reexecutada após uma queda. Para um destino não idempotente, passe na própria chamada uma chave de idempotência derivada de um campo de negócio estável (um ID de pedido, um payment intent).

As oito falácias: um alicerce para a falha

Para entender de verdade por que o Glue Code falha, precisamos voltar às oito falácias da computação distribuída, articuladas pela primeira vez por Peter Deutsch e outros na Sun Microsystems. São as suposições falsas que todo desenvolvedor faz quando começa a escrever código em rede. São os "falsos paraísos" da engenharia:

1. A rede é confiável: Não é. Pacotes se perdem, roteadores reiniciam e cabos são cortados. Em um ambiente de nuvem, em escala, você pode esperar uma falha de rede intermitente todos os dias.

2. A latência é zero: Não é. Mesmo as redes de fibra globais mais rápidas introduzem milissegundos de atraso que se acumulam ao longo de milhares de chamadas. Esse atraso é irregular e imprevisível, levando a race conditions que desaparecem quando você tenta depurá-las localmente.

3. A largura de banda é infinita: Não é. Payloads grandes vão entupir seus canos e disparar timeouts. Provedores de nuvem também têm cotas de banda rígidas que vão limitar seu "Glue Code" sem aviso.

4. A rede é segura: Não é. Ataques man-in-the-middle, envenenamento de DNS e tokens vazados são ameaças constantes. Seu script de "Glue Code" é um alvo preferencial para roubo de credenciais se não estiver bem isolado.

5. A topologia não muda: Muda. Load balancers se deslocam, nós morrem e endereços IP são reciclados. O "IP hardcoded" do seu script é uma bomba-relógio.

6. Existe um único administrador: Não existe. Você está à mercê da AWS, da Cloudflare e de cada provedor SaaS da sua stack. Quando eles mudam a API, seu script é a primeira vítima.

7. O custo de transporte é zero: Não é. Serializar e desserializar JSON em escala tem um custo real de CPU e memória. Um script pode passar uma fração surpreendente do seu tempo apenas fazendo parse e re-parse de payloads em json.loads().

8. A rede é homogênea: Não é. Sua stack é uma mistura de Linux, Windows, JVM, Node e serviços SOAP legados. Esperar um comportamento fixo nesse cenário é uma ilusão.

Mergulho técnico: event sourcing e escalabilidade da persistência

Uma das partes mais difíceis de construir um motor de orquestração durável é gerenciar a persistência do estado. Quando um grande volume de workflows roda simultaneamente e cada um executa muitas etapas, a carga de escrita sobre a camada de persistência cresce rapidamente.

O gargalo do banco de dados

Um esquema ingênuo — uma linha workflow_history larga e mutável, reescrita com o estado completo a cada etapa — acabará cedendo sob essa carga, porque a contenção de índices e locks nas linhas quentes se torna o principal gargalo. O SchemaBridge divide o problema em dois no PostgreSQL: um pequeno registro de estado atual que muda e um histórico que só cresce.

1. Linhas de status pequenas e protegidas: O estado atual de cada execução e de cada etapa fica em linhas de status compactas, atualizadas com escritas condicionais no estilo compare-and-set (uma etapa só passa de DISPATCHED para EXECUTING se ninguém a reivindicou antes). Payloads grandes ficam totalmente fora dessas linhas e são descarregados em um object store SeaweedFS (compatível com S3), e o Valkey Streams cuida da entrega do trabalho entre os estágios.

2. Traces de execução append-only: Cada etapa também acrescenta um registro de trace imutável, o que dá a você uma trilha passo a passo da execução. A tabela de traces é particionada por mês, de modo que partições antigas são descartadas de forma barata quando passam do período de retenção, em vez de serem apagadas linha a linha.

3. Recuperação de falhas sem reidratação: Como o estado atual é durável, um worker nunca precisa reconstruí-lo em memória. Se um worker morre no meio de uma etapa, a reivindicação da etapa expira e outro worker a retoma e a reexecuta. Isso é execução at-least-once, e é exatamente por isso que o conselho acima sobre idempotência de saída importa.

A lacuna de governança: de quem é o encanamento?

Além dos desafios técnicos, existe um cultural: a lacuna de governança. Em uma arquitetura de microsserviços tradicional, a responsabilidade é dividida em silos. O time do "Product Service" é dono do banco de dados de produtos. O time do "Shipping Service" é dono da integração com a FedEx.

Mas quem é dono da ponte entre eles?

Normalmente, ninguém. O script de "Glue Code" é escrito por um desenvolvedor que precisa de uma correção rápida e depois é abandonado. Quando quebra, o time de Product culpa o de Shipping, e o de Shipping culpa o provedor da API. Não existe uma "fonte da verdade" central sobre como os processos de negócio estão de fato conectados.

O SchemaBridge resolve isso tornando a integração um ativo global.

A metáfora biológica: software como sistema nervoso

Estamos caminhando para um mundo em que o software não é mais uma coleção de ferramentas estáticas, e sim um sistema nervoso vivo. Em um sistema nervoso biológico, um sinal viaja do dedo (o sensor) até o cérebro (a lógica) e volta ao músculo (a ação). Se parte do caminho é bloqueada, o sistema se adapta. Ele tem reflexos. Ele tem memória.

A orquestração durável é o sistema nervoso da empresa. Ela permite que seus serviços fragmentados funcionem como um único organismo coeso.

1. Os reflexos: Retries automáticos com backoff absorvem pequenas "dores" (um 5xx transitório, uma resposta de rate limit, uma conexão interrompida em uma chamada HTTP) sem envolver o cérebro (o desenvolvedor).

2. A memória: O estado de execução é persistido, então, após um reinício — mesmo de todo o cluster —, as etapas em andamento são retomadas e reexecutadas em vez de esquecidas. Como essa reexecução é at-least-once, os efeitos colaterais ainda precisam ser idempotentes no destino.

3. A consciência: A observabilidade visual (veja A lacuna de observabilidade) permite que você veja cada execução em tempo real: qual etapa está rodando, qual falhou e o payload que entrou e saiu.

Cenário ilustrativo: o colapso silencioso da conciliação

Para entender a gravidade da crise, considere uma fintech que concilia as transações diárias entre seu livro-razão interno e as APIs de vários bancos parceiros usando um grande conjunto de scripts Python.

A falha

Imagine que, em uma sexta-feira, um banco parceiro troca o esquema de autenticação da sua API de conciliação. O script Python não cai; ele simplesmente é rejeitado, captura a exceção e marca "silenciosamente" a conciliação do dia como "Pending". Como não há um painel visual, a falha passa despercebida por dias.

Quando alguém finalmente olha, uma discrepância grande e crescente se acumulou entre o livro-razão e os bancos. Os auditores são envolvidos, a liderança é notificada e o time de engenharia precisa passar dias reconstruindo manualmente a linha do tempo da conciliação. O script funcionava perfeitamente no "happy path", mas tinha zero capacidade de "autocorreção" e zero "verdade visual".

A alternativa com SchemaBridge

Agora imagine a mesma lógica de conciliação rodando no SchemaBridge. Quando uma mudança de autenticação semelhante acontece, o vertex Gateway (a chamada HTTP de saída para o banco) falha, e a execução fica vermelha no monitor, com a resposta rejeitada anexada à etapa que falhou. O SchemaBridge não aciona ninguém por conta própria, mas o time pode tornar esse caso bem visível: com o clientErrorMode do gateway definido como complete, uma chamada rejeitada (4xx) vira um resultado invalid_input sobre o qual é possível rotear, direto para uma etapa de notificação no Slack. De qualquer forma, a falha fica visível no mesmo dia, e não dias depois. O time corrige a credencial, clica em Retry (Tentar novamente) na etapa que falhou, e a conciliação é retomada de onde parou, em vez de ser reconstruída à mão.

Recursos recomendados para uma orquestração sem erros

Se você quer dominar a arte da execução durável, recomendamos esta lista de leitura selecionada:

Conclusão: o novo mandato do arquiteto

A crise do Glue Code é o sintoma de uma transição. Estamos saindo de um mundo de "silos e scripts" para um mundo de "ecossistemas conectados". Nesse novo mundo, as conexões entre seus serviços são tão importantes quanto os próprios serviços.

Seu mandato como arquiteto não é mais apenas construir serviços confiáveis; é construir conexões confiáveis. O Glue Code é a antítese da confiabilidade. É um remendo temporário que inevitavelmente vira um fardo permanente. É hora de parar de construir canos frágeis e começar a construir um sistema nervoso digital.

Ao adotar um motor de orquestração durável como o SchemaBridge, você retoma o futuro da sua engenharia. Você constrói sistemas que conhecem o próprio estado, resistem a falhas e são visíveis para toda a organização. É assim que você recupera sua velocidade e constrói sistemas que duram.

Este artigo faz parte da nossa série Building the Bridge. Veja também: Projetando para a velocidade: o argumento a favor da ingestão de eventos sem schema — a abordagem de late binding para a ingestão de eventos.

Explorar