Compilando Workflows em Bancos de Dados: A Arquitetura Inesperada

Workflows duráveis podem ser implementados diretamente no seu banco de dados existente, eliminando a necessidade de orquestradores externos e aumentando a confiabilidade e a baixa latência, especialmente para cargas de trabalho de IA. Esta é a premissa central de uma nova abordagem que trata a orquestração como dados, aproveitando a robustez dos sistemas de gerenciamento de banco de dados.

O Problema da Orquestração Distribuída e a Dor do Desenvolvedor

A orquestração de workflows em ambientes distribuídos, especialmente com a ascensão da Inteligência Artificial, tem se tornado um desafio cada vez mais complexo para os profissionais de TI. A dependência de múltiplos sistemas e a movimentação constante de dados resultam em architectures que são difíceis de manter e caras para escalar.

O Caos da Coordenação Externa

Muitos de nós já construímos arquiteturas para processar milhões de documentos ou gerenciar fluxos de dados complexos com IA. O padrão comum inclui microsserviços, filas de mensagens como RabbitMQ ou Kafka, e diversos coordenadores. Essa abordagem, embora funcional, é intrinsecamente frágil. Cada componente adicionado, seja um serviço de download, um processador de IA ou um coordenador de tarefas, representa um novo ponto de falha potencial.

Quando um componente falha, o que é comum em sistemas distribuídos, a recuperação se torna um pesadelo. A complexidade aumenta exponencialmente, e a visibilidade sobre o estado real do workflow é mínima. É difícil saber quais tarefas falharam, quais estão em retry, ou o que exatamente está na fila, a menos que você construa um sistema de logging e monitoramento separado e igualmente complexo.

O Custo Oculto da Inconfiabilidade em Workflows de IA

Falhas em workflows podem ser extremamente caras. Com a crescente dependência de IA para tomar decisões críticas, um erro ou uma interrupção pode ter consequências significativas, desde transações financeiras incorretas até respostas inadequadas a usuários. A demanda por execução "exactly once" (exatamente uma vez) tornou-se primordial, pois os clientes têm cada vez menos tolerância a erros e lentidão.

Além disso, o uso de IA é oneroso. Cada chamada de API, cada reprocessamento devido a uma falha, aumenta os custos operacionais. Ter um sistema que garante a resiliência e a reexecução eficiente é crucial para otimizar o uso de recursos de IA e evitar gastos desnecessários. A falta de visibilidade em soluções de workflow atuais agrava o problema, tornando a depuração e a recuperação processos demorados e dispendiosos.

A Falha das Ferramentas Atuais para Workloads de IA

As ferramentas de orquestração existentes foram, em grande parte, projetadas para workloads de web tradicionais (respostas em milissegundos) ou jobs em lote (tarefas lentas sem interação direta do usuário). Workflows de IA, que podem levar segundos ou minutos para serem concluídos e exigem que o usuário aguarde ou retorne mais tarde, caem em um meio-termo para o qual as soluções atuais não são otimizadas. Isso gera uma lacuna onde a orquestração é dispersa por múltiplos sistemas, aumentando a movimentação de dados – o aspecto mais caro de qualquer sistema distribuído.

A Proposta DBOS: Workflows como Dados no seu Banco de Dados

A solução proposta pela DBOS (Database Operating System) é revolucionária: usar o banco de dados que você já possui para gerenciar o estado e os workflows. Tratar os workflows como dados abre uma nova perspectiva sobre a construção de sistemas distribuídos e resilientes.

Por que o Banco de Dados é a Solução Ideal?

Bancos de dados são sistemas extremamente robustos, desenvolvidos e aprimorados por mais de 50 anos para manipular, armazenar e gerenciar dados de forma eficiente e confiável. Eles já lidam com transações, durabilidade e concorrência, características essenciais para a execução de workflows.

Ao centralizar o estado do workflow no banco de dados, eliminamos a necessidade de coordenadores externos, reduzimos a complexidade da arquitetura e minimizamos a movimentação de dados. Seu banco de dados existente, que já armazena dados de usuário e transações, pode ser reaproveitado para a orquestração, transformando o problema de resiliência em um desafio de gerenciamento de dados.

O Conceito de Execução Durável

A execução durável é a capacidade de um workflow de sobreviver a falhas e continuar de onde parou, sem repetir trabalho ou perder progresso. Imagine um videogame que salva seu progresso automaticamente: se o sistema falha, você pode recarregar o último save point e continuar jogando. A execução durável aplica o mesmo princípio aos workflows de software.

Para alcançar isso, são necessários dois componentes essenciais: um mecanismo para fazer <em>checkpoints</em> do estado da execução (entradas, saídas, status) em um armazenamento durável (o banco de dados) e uma forma de recuperar workflows interrompidos a partir desses checkpoints, pulando as etapas já concluídas para garantir a execução "exactly once".

O Funcionamento Básico do DBOS Transact

O DBOS Transact, uma biblioteca de código aberto disponível para Python, TypeScript, Go e Java, exemplifica essa abordagem. Ele opera sobre o PostgreSQL, mas o conceito é aplicável a qualquer banco de dados relacional. Em vez de orquestradores externos, o Transact usa tabelas padrão, filas <code>SKIP LOCKED</code> e chaves primárias únicas para gerenciar workflows.

Ao registrar funções como workflows ou etapas, a biblioteca as 'embrulha' com lógica para persistir seu estado no banco de dados. Isso significa que, se um servidor falhar, todas as informações necessárias para retomar o workflow estarão presentes no banco, permitindo uma recuperação transparente e eficiente.

Construindo seu Próprio Workflow Durável: Detalhes Técnicos

A implementação de um sistema de workflow durável baseado em biblioteca, como o DBOS Transact, exige algumas considerações técnicas sobre como o estado é salvo e recuperado no banco de dados.

O Wrapper de Workflow

Quando uma função é designada como um workflow, ela é envolvida por um 'wrapper' que gerencia sua durabilidade. As etapas principais incluem:

• <strong>Geração de ID:</strong> Um ID de workflow único é gerado para identificar cada instância do workflow, atuando como uma chave de idempotência.
• <strong>Checkpoint de Entrada:</strong> Os inputs do workflow e o ID são armazenados no banco de dados, marcando o workflow como <code>PENDING</code>.
• <strong>Execução da Função:</strong> A função do workflow é executada normalmente.
• <strong>Checkpoint de Saída:</strong> Ao final da execução, ou em caso de erro, o resultado ou erro é capturado e armazenado no banco, e o status do workflow é atualizado.

O Wrapper de Etapa (Step)

Similarmente, cada etapa (step) dentro de um workflow também é envolvida por um wrapper para garantir sua durabilidade e execução "exactly once":

• <strong>Identificação da Etapa:</strong> O ID do workflow e um ID de etapa único são recuperados do contexto, permitindo identificar a execução da etapa.
• <strong>Verificação de Checkpoint:</strong> A biblioteca verifica se já existe um checkpoint para esta etapa no banco de dados. Se sim, o resultado armazenado é retornado, evitando a reexecução e garantindo a idempotência.
• <strong>Execução da Função:</strong> A função da etapa é executada.
• <strong>Checkpoint de Saída:</strong> O output da etapa é armazenado no banco de dados, atualizando seu estado.

Recuperação de Falhas e Execução "Exactly Once"

Após uma falha (ex: queda do servidor, OOM), o processo de recuperação envolve listar todos os workflows com status <code>PENDING</code> no banco de dados. Para cada um, a biblioteca:

• Recupera os inputs originais do workflow.
• Identifica a definição da função do workflow através de um mapa de funções registradas.
• Reexecuta o workflow com seu ID original e inputs gravados.

Estrutura das Tabelas no Banco de Dados

A simplicidade da abordagem se reflete na estrutura do banco de dados. Duas tabelas são geralmente suficientes para a implementação básica:

• <strong><code>workflow_status</code>:</strong> Armazena metadados gerais de cada execução de workflow (ID, nome, status, inputs, outputs).
• <strong><code>step_outputs</code>:</strong> Registra os outputs de cada etapa individual do workflow, com uma chave estrangeira para o ID do workflow pai.

Vantagens da Abordagem Baseada em Biblioteca

A implementação de workflows como uma biblioteca sobre um banco de dados traz uma série de benefícios significativos, desde a experiência do desenvolvedor até a eficiência operacional.

Experiência do Desenvolvedor e Integração

A maior vantagem é a harmonização com o ecossistema existente. Você não precisa refatorar toda a sua aplicação para se adequar a um novo framework. Basta instalar a biblioteca, registrar suas funções como workflows ou etapas, e invocá-las. Isso funciona perfeitamente com frameworks populares como FastAPI, Spring Boot, ou bibliotecas de IA como LangChain, pois a abordagem é agnóstica a frameworks e linguagens, focando em uma experiência familiar ao desenvolvedor.

Redução de Custos Operacionais e Latência

Com esta arquitetura, os custos operacionais são drasticamente reduzidos. Não há servidores ou pools de workers separados para gerenciar; a biblioteca roda <em>in-process</em> com sua aplicação. Você pode reutilizar seu cluster Kubernetes, funções serverless ou servidores de aplicação existentes. A simplicidade inerente a essa abordagem também melhora a velocidade. Enquanto soluções distribuídas envolvem múltiplas viagens de ida e volta a orquestradores e bancos de dados externos, a abordagem baseada em biblioteca reduz o overhead a poucas escritas no banco de dados por workflow e por etapa.

Ao co-localizar o servidor de aplicação com o banco de dados, a latência de comunicação é minimizada, geralmente caindo para alguns milissegundos.

Gerenciamento de Workflows via SQL e o Conceito de "Fork"

Como todas as informações de workflow estão no banco de dados, o gerenciamento pode ser feito inteiramente via queries SQL. É possível listar, pesquisar, cancelar ou retomar workflows com facilidade usando comandos SQL padrão. Essa capacidade também desbloqueia o conceito de "fork" de workflows, uma analogia ao Git.

Se um workflow falha em uma etapa específica devido a um bug, você pode criar um "fork" a partir daquele ponto. A biblioteca copia os inputs e outputs das etapas concluídas para um novo ID de workflow. Em seguida, o novo workflow é executado com o código corrigido, pulando as etapas já bem-sucedidas e retomando da etapa onde o problema ocorreu. Isso é extremamente útil para recuperação de desastres e correção de bugs em produção.

Desafios e Soluções na Orquestração com Banco de Dados

Embora a abordagem de banco de dados para workflows ofereça muitas vantagens, ela apresenta desafios específicos que precisam ser endereçados, principalmente relacionados à escalabilidade e à orquestração descentralizada.

O Desafio da Scalabilidade e a Limitação da Linguagem

Um dos desafios fundamentais é a necessidade de construir uma biblioteca personalizada para cada linguagem de programação (Python, Java, Go, TypeScript). Isso ocorre porque a experiência do desenvolvedor precisa ser adaptada a idiossincrasias de cada linguagem, como funções síncronas/assíncronas ou injeção de dependência. No entanto, o esquema do banco de dados e as queries SQL subjacentes podem ser compartilhados, concentrando o esforço de desenvolvimento na interface do usuário da biblioteca.

Em termos de escalabilidade, a principal limitação é o throughput de escrita do banco de dados. Cada workflow exige duas escritas e cada etapa uma escrita. Embora bancos de dados modernos, como PostgreSQL, sejam altamente escaláveis (suportando dezenas de milhares de transações por segundo), eventualmente, a latência de escrita pode se tornar um gargalo. A solução reside nas estratégias tradicionais de escalabilidade de bancos de dados, como sharding ou ofertas de bancos de dados distribuídos. Profissionais de TI no Brasil já enfrentam isso ao otimizar a persistência de dados em grandes aplicações.

Implementando Filas (Queues) com SKIP LOCKED

Filas são essenciais para agrupar e ordenar workflows para execução em lote ou em segundo plano. Em vez de introduzir um sistema de filas externo, a tabela <code>workflow_status</code> pode ser estendida com colunas como <code>queue_name</code>, <code>created_at</code> e <code>priority</code>. Isso integra a durabilidade e facilita o controle de fluxo e rate limits diretamente via SQL.

O grande desafio surge com múltiplos workers acessando a mesma fila baseada em polling. Se vários workers tentam selecionar o mesmo workflow ao mesmo tempo, ocorre contenção de locks no banco de dados. A solução elegante para isso é usar a cláusula <code>FOR UPDATE SKIP LOCKED</code> do PostgreSQL (ou implementações equivalentes em outros bancos). Esta cláusula permite que um worker selecione uma linha para processamento e a bloqueie, enquanto outros workers pulam as linhas já bloqueadas e buscam a próxima tarefa disponível. Isso elimina a contenção de locks e otimiza o desempenho em ambientes com muitos workers.

Agendamento Cron Descentralizado e Jitter Aleatório

Executar workflows em horários agendados (cron jobs) sem um orquestrador central também é um desafio. A solução é que cada worker execute seu próprio agendador cron. O truque é usar o tempo agendado como ID de workflow (chave de idempotência). Devido à restrição de chave primária, o banco de dados garante que apenas um worker consiga registrar o workflow, evitando duplicações.

Para evitar picos de carga quando centenas de workers tentam registrar o mesmo workflow simultaneamente (por exemplo, às 17h00), adiciona-se um "jitter" aleatório (pequeno atraso) ao tempo de ativação de cada worker. Assim, os workers acordam em momentos ligeiramente diferentes. O primeiro a acordar registra o workflow; os demais verificam o banco, veem que já existe e ignoram a execução. Leituras de banco de dados são mais baratas que escritas, resolvendo o gargalo de desempenho.

Benefícios Ampliados: Testes, Segurança e Observabilidade

A abordagem de orquestração interna, centrada no banco de dados, oferece vantagens significativas que se estendem muito além da simples execução de workflows.

Facilidade de Teste e Conformidade

Como a lógica de workflow está encapsulada em uma biblioteca de linguagem, todas as ferramentas existentes para testes de unidade e integração (mocking, frameworks de teste) podem ser utilizadas. Isso simplifica drasticamente a garantia de qualidade. Do ponto de vista de segurança e conformidade, a centralização de todo o estado no banco de dados é um grande benefício. Nenhum dado crítico sai da sua infraestrutura, o que agrada às equipes de segurança. A auditoria se torna trivial, pois cada chamada de função, input e output são registrados e podem ser consultados via SQL, facilitando a detecção de anomalias e a conformidade regulatória.

Observabilidade Simples via SQL

A observabilidade, frequentemente um ponto fraco em sistemas distribuídos complexos, é simplificada. Todas as informações sobre workflows pendentes, em fila, concluídos ou com falha estão disponíveis via queries SQL. Isso permite a criação de dashboards personalizados e a análise de desempenho diretamente do banco de dados, fornecendo insights detalhados sem a necessidade de ferramentas de monitoramento adicionais caras ou complexas. É possível visualizar o progresso de cada etapa, identificar gargalos e monitorar o comportamento do sistema com facilidade.

O Futuro da Orquestração Interna

A visão é clara: mudar de uma orquestração externa e complexa para uma orquestração interna e simplificada, onde o banco de dados é o orquestrador. Isso não apenas simplifica o desenvolvimento, permitindo que os desenvolvedores escrevam código normal sem se preocupar com a re-arquitetura para durabilidade, mas também facilita a integração com ferramentas de IA, que podem interagir mais facilmente com uma base de código unificada do que com múltiplas configurações de YAML e Terraform.

Para o mercado de TI brasileiro, essa abordagem pode representar uma economia significativa em infraestrutura e um ganho de agilidade no desenvolvimento, especialmente para empresas que buscam otimizar seus custos com nuvem e simplificar suas operações de Integração Contínua e Entrega Contínua (CI/CD).

Perguntas Frequentes (FAQ)

Arraste para o lado para ver toda a tabela.

Perguntas Frequentes (FAQ)

Como lidar com workflows que abrangem múltiplas aplicações com bancos de dados diferentes?

É possível ter bibliotecas Transact em cada aplicação, apontando para seus respectivos bancos, e comunicá-las usando chaves de idempotência. Alternativamente, uma aplicação principal pode orquestrar chamadas a outras, que por sua vez executam seus próprios sub-workflows duráveis.

É possível misturar linguagens de programação em um mesmo workflow durável?

Atualmente, as bibliotecas Transact são específicas para cada linguagem, pois a serialização de dados entre linguagens diferentes (como Python e Go) é um desafio complexo. No entanto, é possível usar workflows hierárquicos, onde um workflow em Go dispara sub-workflows em Python, por exemplo.

Como a compensação (undo de ações) é tratada em workflows de longa duração?

A compensação é responsabilidade do desenvolvedor. A vantagem é que, com o estado completo e histórico de inputs/outputs no banco de dados, você tem todas as informações para codificar etapas de compensação dentro do seu workflow, garantindo a reversão controlada de ações.

A execução "exactly once" exige que as etapas individuais sejam idempotentes?

Sim, para garantir a execução "exactly once" em um workflow durável, é um requisito básico que as etapas individuais sejam determinísticas e idempotentes. Isso permite que, em caso de reexecução após uma falha, a etapa produza o mesmo resultado sem efeitos colaterais indesejados.