Microserviços, APIs RESTful e IA: Escalando Automação Empresarial com Inteligência

Introdução

Imagine uma empresa que implementou um sistema de automação para otimizar seu atendimento ao cliente. Inicialmente, a solução funcionou bem, integrando um chatbot com um CRM para triagem de chamados. Com o tempo, a demanda cresceu, e novas funcionalidades foram adicionadas: análise de sentimento em feedbacks, roteamento inteligente de tickets para equipes especializadas e até mesmo um módulo de recomendação de produtos baseado em histórico. O que começou como uma solução elegante e eficiente, gradualmente se transformou em um emaranhado de código, onde cada nova funcionalidade exige semanas de desenvolvimento e testes e introduz riscos de quebra em partes já existentes. A equipe se sente presa, incapaz de inovar rapidamente e com medo de introduzir novas tecnologias, como modelos de Machine Learning mais avançados, por receio de desestabilizar o sistema. Essa é a dura realidade de muitas empresas que, ao tentar escalar suas automações, acabam construindo um monólito de complexidade, sufocando o próprio crescimento e a agilidade que buscavam.

Contexto do Problema

O cenário tecnológico atual exige agilidade e escalabilidade. Empresas buscam otimizar processos, reduzir custos operacionais e melhorar a experiência do cliente através da automação. A Inteligência Artificial (IA), especialmente em suas vertentes de Machine Learning (ML) e Processamento de Linguagem Natural (PNL), oferece um potencial imenso para elevar essas automações a um novo patamar de inteligência e eficiência. No entanto, a forma como essas soluções são arquitetadas e integradas é crucial. Sistemas monolíticos, onde toda a lógica de negócio reside em uma única aplicação, tornam-se gargalos à medida que crescem. Adicionar novas funcionalidades, atualizar componentes, escalar partes específicas do sistema ou integrar novas tecnologias (como um novo modelo de IA) torna-se uma tarefa hercúlea, demorada e arriscada. A complexidade aumenta exponencialmente, os tempos de deploy se estendem e a capacidade de resposta a mudanças de mercado ou novas oportunidades de negócio é severamente comprometida. Em muitos casos, a tentativa de adicionar IA a um sistema monolítico existente resulta em integrações "cola" e dependências ocultas que tornam o sistema frágil e difícil de manter, minando o retorno sobre o investimento em inovação.

Como resolvemos esse problema na prática

Em um projeto recente para uma empresa de logística, o desafio era escalar um sistema de rastreamento de mercadorias que utilizava regras de negócio fixas e processava dados de forma sequencial. Eles queriam adicionar inteligência para prever atrasos com base em padrões climáticos, tráfego e histórico de entregas, além de otimizar rotas em tempo real. A abordagem inicial da empresa era integrar um modelo de ML diretamente no sistema existente, o que geraria um monolito ainda maior e mais difícil de gerenciar.

Nossa solução focou em desmembrar a funcionalidade em serviços menores e independentes, seguindo os princípios de arquitetura de microserviços e utilizando APIs RESTful para comunicação. O sistema foi reestruturado da seguinte forma:

1. Serviço de Ingestão de Dados: Responsável por receber e validar dados de diversas fontes (sensores de veículos, APIs de clima, sistemas de tráfego). Este serviço era escalável horizontalmente para lidar com picos de dados.
2. Serviço de Rastreamento Central: Mantinha a lógica de rastreamento básica e o estado atual de cada mercadoria. Ele se comunicava com outros serviços via API.
3. Serviço de Previsão de Atrasos (IA): Um microserviço dedicado que consumia dados do serviço de ingestão e do serviço de rastreamento. Ele executava modelos de ML treinados para prever a probabilidade e o tempo estimado de atrasos. Este serviço podia ser atualizado e escalado independentemente, permitindo experimentar diferentes modelos de IA sem afetar o funcionamento do rastreamento principal.
4. Serviço de Otimização de Rotas (IA): Outro microserviço, este utilizando algoritmos de otimização (como o Problema do Caixeiro Viajante ou variações) e incorporando as previsões de atraso. Ele recebia requisições com múltiplos pontos de entrega e retornava rotas otimizadas.
5. API Gateway: Ponto de entrada único para todas as requisições externas, direcionando-as para os serviços apropriados e cuidando de autenticação e rate limiting.

As APIs RESTful foram o "cimento" que uniu esses serviços. Por exemplo, o Serviço de Rastreamento Central, ao precisar de uma previsão de atraso para uma rota específica, fazia uma requisição GET para o Serviço de Previsão de Atrasos, passando os parâmetros necessários (origem, destino, carga, etc.). O Serviço de Previsão respondia com um JSON contendo a probabilidade de atraso e o tempo estimado. Da mesma forma, o Serviço de Otimização de Rotas consultava os outros serviços via API.

Essa arquitetura permitiu que a empresa adicionasse novas fontes de dados (integrando um novo serviço de monitoramento de tráfego em tempo real apenas no Serviço de Ingestão), atualizasse os modelos de IA (substituindo o Serviço de Previsão de Atrasos por uma versão mais avançada sem impactar o resto do sistema) e escalasse apenas os serviços que apresentavam maior carga (como o Serviço de Ingestão durante picos de dados), tudo isso de forma independente e com riscos minimizados. A complexidade foi encapsulada dentro de cada serviço, tornando o sistema como um todo mais gerenciável e flexível.

Implementação Técnica

A adoção de uma arquitetura de microserviços e APIs RESTful para escalar automações empresariais com IA envolve decisões técnicas cruciais e trade-offs conscientes.

Tecnologias e Padrões:

• Linguagens e Frameworks: A escolha das linguagens pode variar por serviço. Por exemplo, Python é excelente para serviços de IA (com bibliotecas como TensorFlow, PyTorch, Scikit-learn), enquanto Node.js ou Go podem ser ideais para serviços de alta performance e I/O intensivo (como gateways ou serviços de ingestão de dados). Java com Spring Boot ou C# com .NET Core são opções robustas para serviços de negócio mais tradicionais.
• APIs RESTful: Utilização de HTTP como protocolo de comunicação, com verbos (GET, POST, PUT, DELETE) para operações e formatos de dados como JSON para troca de informações. Padrões como OpenAPI (Swagger) são essenciais para documentar e padronizar as APIs, facilitando a integração e o consumo por outros serviços.
• Contêinerização e Orquestração: Docker para empacotar cada microserviço em contêineres isolados, garantindo consistência entre ambientes de desenvolvimento, teste e produção. Kubernetes (K8s) para orquestrar esses contêineres, automatizando deploy, escalonamento, auto-recuperação e gerenciamento de recursos. Isso é fundamental para a escalabilidade automática.
• Comunicação Assíncrona: Para desacoplar ainda mais os serviços e lidar com operações que não exigem resposta imediata, filas de mensagens como RabbitMQ ou Kafka são implementadas. Por exemplo, um serviço de processamento de imagem pode publicar um evento em uma fila, e múltiplos serviços de IA podem assinar essa fila para processar a imagem em paralelo.
• Bancos de Dados: Cada microserviço idealmente possui seu próprio banco de dados, escolhido com base na necessidade específica do serviço (ex: PostgreSQL para dados relacionais, MongoDB para documentos, Redis para cache). Isso reforça a autonomia e o desacoplamento.
• IA/ML: Modelos de Machine Learning podem ser desenvolvidos e treinados separadamente. Para deploy, podem ser expostos como APIs RESTful (ex: usando Flask/FastAPI em Python) ou integrados a serviços de orquestração de ML como Kubeflow.

Arquitetura e Integrações:

• API Gateway: Um componente centralizado (ex: Nginx, Kong, AWS API Gateway) que atua como a porta de entrada para todas as requisições externas. Ele pode lidar com autenticação (OAuth2, JWT), autorização, rate limiting, roteamento e agregação de respostas de múltiplos serviços.
• Service Discovery: Mecanismos (como Consul, Eureka, ou funcionalidades nativas do Kubernetes) que permitem que os microserviços encontrem uns aos outros dinamicamente na rede, sem a necessidade de configurar endereços IP fixos.
• Gerenciamento de Estado: Como os serviços são independentes, o gerenciamento de transações distribuídas e a consistência de dados entre serviços (eventual consistency) tornam-se desafios. Padrões como Saga Pattern podem ser aplicados para gerenciar fluxos de trabalho que abrangem múltiplos serviços.
• Observabilidade: Essencial em um ambiente distribuído. Implementação de logging centralizado (ELK Stack, Loki), monitoramento de métricas (Prometheus, Grafana) e tracing distribuído (Jaeger, Zipkin) para entender o fluxo de requisições através dos serviços e diagnosticar problemas rapidamente.

Decisões e Trade-offs:

• Complexidade Operacional vs. Complexidade de Código: A transição para microserviços aumenta a complexidade operacional (gerenciamento de múltiplos serviços, redes, deploy, observabilidade). No entanto, a complexidade de código de cada serviço individual é reduzida, tornando-o mais fácil de entender, desenvolver e manter. O trade-off é aceitar uma maior carga de infraestrutura e DevOps em troca de maior agilidade e escalabilidade do negócio.
• Consistência Forte vs. Consistência Eventual: Em um monolito, transações ACID são relativamente simples de implementar. Em microserviços, garantir consistência de dados entre serviços pode exigir o uso de consistência eventual, que é mais complexa de raciocinar e implementar, mas necessária para manter o desacoplamento e a performance.
• Custo de Infraestrutura: Um ambiente de microserviços, especialmente com orquestração (Kubernetes), tende a ter um custo de infraestrutura inicial mais alto devido à necessidade de mais recursos de rede, orquestração e monitoramento. No entanto, o escalonamento granular e a otimização de recursos podem levar a um custo total menor em larga escala, pois apenas os serviços demandados consomem recursos.
• Comunicação Síncrona vs. Assíncrona: APIs RESTful síncronas são mais fáceis de entender e depurar inicialmente. Comunicações assíncronas (filas de mensagens) aumentam a resiliência e o desacoplamento, mas adicionam complexidade ao rastreamento de fluxos e tratamento de falhas.

Exemplo de Fluxo de Dados com IA:

Uma empresa de e-commerce quer personalizar recomendações de produtos com base no comportamento do usuário em tempo real.

1. O Frontend envia um evento user_viewed_product para o API Gateway.
2. O Gateway encaminha para o Serviço de Eventos de Usuário, que publica o evento em uma fila Kafka.
3. Um Serviço de Processamento de Histórico consome esse evento, atualiza o perfil do usuário em seu banco de dados (ex: MongoDB).
4. Um Serviço de Recomendação (IA), que observa as atualizações no perfil do usuário ou consome eventos específicos, utiliza um modelo de ML para gerar recomendações. Ele pode expor essas recomendações via API RESTful.
5. Quando o usuário visita a página inicial, o Frontend chama a API Gateway (que delega ao Serviço de Recomendação) para buscar as recomendações personalizadas.

Neste fluxo, a IA está encapsulada em um serviço dedicado, que pode ser escalado e atualizado independentemente. A comunicação via eventos e APIs garante o desacoplamento e a resiliência.

Benefícios Obtidos

A adoção de microserviços e APIs RESTful para automação com IA não é isenta de desafios, mas os benefícios em termos de escalabilidade, agilidade e inovação são significativos. Em cenários comuns, observamos os seguintes ganhos:

• Escalabilidade Granular: Em projetos onde a demanda por processamento de dados de IA (como análise de vídeo ou processamento de linguagem natural em larga escala) é muito maior do que a lógica de negócio central, podemos escalar apenas os serviços de IA. Por exemplo, em uma plataforma de análise de dados de sensores, o serviço que processa os dados brutos e aplica modelos de detecção de anomalias pode ser escalado independentemente do serviço que gerencia os usuários e permissões. Um ganho esperado pode ser a redução de custos de infraestrutura em até 40% em comparação com o escalonamento de um monolito onde todos os componentes são replicados, além de garantir performance mesmo em picos de uso.
• Agilidade no Desenvolvimento e Deploy: Equipes menores podem trabalhar de forma independente em serviços específicos. Isso acelera o ciclo de desenvolvimento e deploy. Em um projeto de automação de marketing, a equipe responsável pelo motor de recomendação (IA) pode lançar novas versões de seu modelo e algoritmos semanalmente, enquanto a equipe de CRM continua a trabalhar em suas funcionalidades, sem bloqueios mútuos. Estimamos que o tempo de lançamento de novas funcionalidades críticas possa ser reduzido em até 60%.
• Facilidade de Inovação com IA: A arquitetura de microserviços facilita a experimentação com novas tecnologias de IA. Podemos desenvolver um novo microserviço de IA para detecção de fraude, por exemplo, testá-lo isoladamente e, se bem-sucedido, integrá-lo ao fluxo principal através de chamadas API. Se o novo serviço não performar como esperado, ele pode ser desativado ou substituído sem afetar os sistemas existentes. Isso reduz o risco de introduzir IA em ambientes de produção e acelera o tempo de chegada de novas capacidades ao mercado.
• Resiliência e Tolerância a Falhas: Se um microserviço falha, ele não derruba todo o sistema. Outros serviços podem continuar operando. Por exemplo, em um sistema de gestão de fluxos de trabalho, se o serviço de notificação por e-mail falhar temporariamente, os demais fluxos de trabalho continuam sendo processados e os dados são persistidos. As notificações podem ser reenviadas assim que o serviço for restaurado. Isso pode aumentar a disponibilidade do sistema para mais de 99.9%.
• Manutenção e Atualização Simplificadas: Atualizar ou substituir uma tecnologia específica (ex: migrar um serviço de Python 2 para Python 3, ou substituir uma biblioteca de ML) torna-se uma tarefa contida em um único microserviço. Isso minimiza o risco de introduzir bugs em outras partes do sistema e reduz o tempo de manutenção. Em um sistema legado que utilizava um framework desatualizado, a migração de um módulo específico para uma tecnologia moderna levou apenas duas semanas, em vez de meses que levaria para migrar um monolito inteiro.
• Otimização de Recursos: Cada serviço pode ser configurado com os recursos de computação (CPU, memória) mais adequados às suas necessidades específicas. Serviços de IA que consomem muita CPU durante o treinamento ou inferência podem receber mais recursos, enquanto serviços mais leves podem ser executados em instâncias menores, otimizando o custo total de infraestrutura.

Estes benefícios, quando bem implementados, traduzem-se diretamente em maior capacidade de resposta ao mercado, redução de custos operacionais, melhor experiência do cliente e um ciclo de inovação contínuo.

Erros Mais Comuns

Ao migrar para microserviços ou ao tentar escalar automações com IA, muitas empresas cometem erros que geram retrabalho, desperdício de recursos e frustração. Conhecer esses erros é o primeiro passo para evitá-los:

1. Criar um Monolito Distribuído (Distributed Monolith): Este é talvez o erro mais comum. Ocorre quando os serviços são pequenos, mas rigidamente acoplados. Um serviço chama diretamente outro serviço de forma síncrona para operações críticas, e ambos compartilham esquemas de banco de dados ou dependem fortemente de implementações internas uns dos outros. O resultado é que, embora existam múltiplos serviços, qualquer mudança em um requer modificações em vários outros, e um serviço falho pode derrubar vários outros. A complexidade de deploy e teste se torna um pesadelo. Por que gera retrabalho: A equipe acaba tendo que refatorar o acoplamento, introduzir padrões de comunicação assíncrona ou filas e desacoplar bancos de dados, o que é muito mais difícil do que construir a arquitetura corretamente desde o início.

2. Ignorar a Complexidade Operacional: Adotar microserviços sem investir em automação de infraestrutura (CI/CD), monitoramento e logging centralizado. A gestão de dezenas ou centenas de serviços em produção sem ferramentas adequadas é inviável. Por que gera retrabalho: Sem observabilidade, diagnosticar problemas se torna impossível. Sem automação de deploy, o processo se torna manual, lento e propenso a erros. A equipe gasta tempo excessivo corrigindo problemas de infraestrutura em vez de focar em valor de negócio, e eventualmente pode ser forçada a "simplificar" a arquitetura, muitas vezes voltando para um modelo mais monolítico, mas com a bagagem técnica dos microserviços não gerenciados.

3. Não Definir Limites Claros de Serviço (Bounded Contexts): Tentar dividir um sistema em serviços sem um entendimento claro dos limites de cada domínio de negócio. Isso leva a serviços que tentam fazer muitas coisas ou serviços que precisam se comunicar excessivamente para realizar uma única tarefa de negócio. Por que gera retrabalho: A equipe gasta tempo reorganizando serviços, fundindo-os ou dividindo-os novamente, o que atrasa o desenvolvimento e gera inconsistências de dados. A falta de limites claros impede a autonomia das equipes e a escalabilidade independente.

4. Comunicação Excessivamente Síncrona: Depender apenas de chamadas HTTP síncronas entre serviços. Isso cria cadeias de dependência onde a falha de um serviço na cadeia pode parar todo o fluxo de requisição. Além disso, aumenta a latência percebida pelo usuário. Por que gera retrabalho: Para mitigar problemas de performance e resiliência, a equipe precisa introduzir mecanismos de cache, retentativas complexas, circuit breakers e, eventualmente, migrar para comunicação assíncrona, o que adiciona complexidade que poderia ter sido evitada.

5. Gerenciamento de Dados Inconsistente: Tentar manter transações distribuídas ACID entre múltiplos serviços ou, pior, compartilhar bancos de dados entre serviços. O compartilhamento de bancos de dados é um dos maiores indicadores de um monolito distribuído. Por que gera retrabalho: A inconsistência de dados leva a erros de negócio e perda de confiança no sistema. A tentativa de implementar transações distribuídas complexas em um ambiente de microserviços sem o uso de padrões como Saga pode levar a estados inconsistentes difíceis de reverter. A refatoração para garantir a consistência eventual ou implementar Sagas é um trabalho árduo.

6. Subestimar o Custo de Testes: Testar um sistema distribuído é inerentemente mais complexo do que testar um monolito. Ignorar isso leva a testes insuficientes e bugs em produção. Por que gera retrabalho: A necessidade de implementar testes de integração mais robustos, testes de contrato entre serviços e testes de ponta a ponta (end-to-end) se torna clara após os primeiros bugs em produção. O retrabalho envolve a criação de uma estratégia de testes mais abrangente e a automação desses testes, o que consome tempo e recursos.

7. Implementar IA sem Estratégia Clara: Tentar adicionar IA a um sistema sem um caso de uso de negócio bem definido ou sem entender os requisitos de dados e infraestrutura. Por exemplo, implementar um modelo de ML pesado em um serviço que não foi projetado para suportar a carga computacional ou a latência necessária. Por que gera retrabalho: O modelo de IA pode não entregar o valor esperado, ou o sistema como um todo pode se tornar instável. A refatoração para otimizar a inferência, ajustar a infraestrutura ou até mesmo escolher um modelo de IA mais adequado se torna necessária.

Evitar esses erros requer um planejamento cuidadoso, uma compreensão profunda dos princípios de arquitetura distribuída e um forte foco em automação e observabilidade.

Conclusão

Escalar automações empresariais com Inteligência Artificial sem cair na armadilha da complexidade de um monólito é um desafio técnico e estratégico. A arquitetura de microserviços, quando combinada com APIs RESTful bem definidas, oferece um caminho robusto para alcançar essa escalabilidade. Ao dividir sistemas complexos em serviços menores, independentes e comunicando-se de forma eficiente, as empresas ganham agilidade para inovar, resiliência para operar e capacidade de escalar componentes específicos conforme a demanda, especialmente aqueles que envolvem processamento de IA.

A chave reside em um planejamento arquitetural cuidadoso, na escolha das tecnologias adequadas para cada serviço, na adoção de padrões de comunicação resilientes (incluindo comunicação assíncrona onde apropriado) e, crucialmente, em um forte investimento em observabilidade e automação de infraestrutura. Os trade-offs, como a maior complexidade operacional em troca de maior agilidade de negócio, devem ser compreendidos e gerenciados proativamente. Erros comuns, como a criação de monolitos distribuídos ou a falta de limites claros entre serviços, podem ser evitados com conhecimento e boas práticas.

Ao abraçar essa abordagem, as empresas podem não apenas otimizar seus processos atuais, mas também posicionar-se para a inovação contínua, aproveitando todo o potencial da Inteligência Artificial para impulsionar o crescimento e a eficiência. Se sua empresa busca implementar ou escalar automações empresariais com inteligência artificial de forma eficiente e escalável, a Devisaah oferece soluções personalizadas de desenvolvimento e consultoria arquitetural.

FAQ

O que é um monólito de complexidade em automação empresarial?

Um monólito de complexidade em automação empresarial refere-se a um sistema onde toda a lógica de negócio, incluindo funcionalidades de IA, está contida em uma única base de código ou aplicação. Conforme novas funcionalidades são adicionadas e a demanda cresce, o sistema se torna cada vez mais difícil de entender, modificar, testar e escalar, devido à interdependência de seus componentes e à dificuldade em isolar e atualizar partes específicas sem afetar o todo. A complexidade não está apenas no código, mas também nas dificuldades operacionais e de manutenção.

Por que microserviços ajudam a evitar um monólito de complexidade?

Microserviços dividem uma aplicação grande em serviços menores, independentes e fracamente acoplados. Cada serviço foca em uma funcionalidade de negócio específica e pode ser desenvolvido, implantado e escalado independentemente. Isso significa que a complexidade é distribuída e encapsulada dentro de cada serviço, tornando o sistema como um todo mais gerenciável e permitindo que novas tecnologias, como IA, sejam integradas ou atualizadas em um serviço sem impactar os demais.

O que são APIs RESTful e como elas se encaixam na arquitetura de microserviços?

APIs RESTful (Representational State Transfer) são um conjunto de princípios para projetar aplicações em rede, utilizando o protocolo HTTP. Elas definem como os serviços devem se comunicar, usando métodos como GET, POST, PUT e DELETE para interagir com recursos, geralmente no formato JSON. Em microserviços, APIs RESTful atuam como o "contrato" de comunicação entre os serviços, permitindo que eles troquem dados e solicitem funcionalidades uns dos outros de maneira padronizada e desacoplada.

Quais são os principais desafios ao integrar IA com microserviços?

Os principais desafios incluem: gerenciar a complexidade da comunicação entre serviços (especialmente com inferência de IA que pode ser intensiva), garantir a consistência de dados em um ambiente distribuído, lidar com o versionamento de modelos de IA e garantir que a infraestrutura de cada serviço de IA seja otimizada para performance e custo. Além disso, a observabilidade (monitoramento, logging, tracing) é mais complexa em sistemas distribuídos.

A arquitetura de microserviços é sempre a melhor opção para automação com IA?

Não necessariamente. Microserviços são ideais para sistemas que precisam de alta escalabilidade, agilidade e onde diferentes partes do sistema têm requisitos de tecnologia ou escalabilidade muito distintos (como módulos de IA). Para aplicações muito simples ou com equipes pequenas, um monolito bem estruturado pode ser mais fácil e rápido de desenvolver inicialmente. A decisão depende do tamanho do projeto, dos requisitos de escalabilidade, da complexidade esperada e da capacidade da equipe de gerenciar a complexidade operacional de microserviços.

Como garantir a segurança em uma arquitetura de microserviços com APIs?

A segurança em microserviços envolve várias camadas: proteger o API Gateway (autenticação, autorização, rate limiting), garantir a comunicação segura entre serviços (ex: mTLS), gerenciar identidades e acessos (ex: OAuth2, JWT), proteger os dados em repouso e em trânsito, e implementar práticas de segurança no desenvolvimento de cada microserviço. A segurança deve ser considerada desde o início do design da arquitetura.

Qual o papel do Kubernetes em uma arquitetura de microserviços e IA?

O Kubernetes (K8s) é um orquestrador de contêineres que automatiza o deploy, escalonamento e gerenciamento de aplicações conteinerizadas (como microserviços). Para IA, ele pode gerenciar contêineres que executam modelos de ML, facilitar o escalonamento automático com base na carga e integrar com ferramentas de ML Ops. O K8s simplifica a gestão da infraestrutura complexa de microserviços, tornando o ambiente mais resiliente e escalável.

Quanto tempo leva para migrar de um monolito para microserviços?

O tempo de migração varia enormemente dependendo do tamanho e complexidade do monolito, da experiência da equipe com arquiteturas distribuídas e da estratégia de migração adotada (ex: "strangler fig pattern"). Pode levar de meses a anos. É um processo gradual, onde funcionalidades são extraídas do monolito para microserviços independentes, em vez de uma grande migração de uma só vez. O foco deve ser em entregar valor continuamente durante o processo de migração.

Como lidar com a consistência de dados entre microserviços?

Em microserviços, a consistência forte (ACID) entre serviços é difícil e geralmente evitada. Em vez disso, adota-se a consistência eventual. Padrões como o Saga Pattern, onde uma sequência de transações locais é executada, e se uma falha ocorrer, transações compensatórias são executadas para reverter as operações anteriores, são comumente usados. Filas de mensagens e eventos também ajudam a gerenciar fluxos de dados e garantir que os serviços eventualmente cheguem a um estado consistente.