Integração, contratos e modernização de sistemas na prática

Introdução

Sistemas modernos raramente funcionam de maneira isolada.

Uma aplicação pode depender de:

• APIs
• Bancos de dados
• Serviços externos
• Filas
• Eventos
• Webhooks
• Aplicações legadas
• Plataformas de terceiros
• Sistemas regulatórios
• Aplicações web e mobile

Por isso, uma das principais decisões arquiteturais está na forma como os componentes desse ecossistema se comunicam.

Essa escolha afeta diretamente:

• Latência
• Disponibilidade
• Resiliência
• Segurança
• Escalabilidade
• Governança
• Capacidade de processamento
• Complexidade operacional
• Custos de infraestrutura

O papel do arquiteto não é apenas escolher uma tecnologia de integração.

É compreender o contexto, avaliar alternativas e justificar cada decisão pelos problemas que ela resolve e pelos impactos que produz.

Integração síncrona e assíncrona

A integração entre sistemas pode ocorrer de maneira síncrona ou assíncrona.

Comunicação síncrona

Na comunicação síncrona, o consumidor envia uma solicitação e aguarda a resposta.

Exemplos:

• REST
• GraphQL
• gRPC

Fluxo conceitual:

Consumidor
↓
Envia solicitação
↓
Fornecedor processa
↓
Resposta é devolvida
↓
Consumidor continua o fluxo

A comunicação síncrona costuma ser adequada quando o consumidor precisa imediatamente do resultado.

Comunicação assíncrona

Na comunicação assíncrona, o produtor publica uma mensagem ou evento sem precisar esperar que todos os consumidores concluam o processamento.

Exemplos:

• Kafka
• RabbitMQ
• Amazon SQS
• Google Pub/Sub
• Amazon EventBridge

Fluxo conceitual:

Produtor
↓
Publica mensagem ou evento
↓
Broker armazena ou distribui
↓
Consumidores processam posteriormente

Esse modelo permite que o sistema de origem continue seu fluxo sem depender da conclusão imediata de todas as etapas seguintes.

Perguntas para orientar a escolha

• O consumidor precisa da resposta imediatamente?
• Quanto tempo ele pode esperar?
• A operação pode continuar caso outro serviço esteja indisponível?
• É necessário absorver picos de demanda?
• A consistência precisa ser imediata?
• Como serão tratados erros e reprocessamentos?
• A ordem das mensagens é relevante?
• O fluxo precisa ser rastreado entre vários componentes?

API como contrato

Uma API, ou Application Programming Interface, define uma interface de comunicação entre sistemas.

Ela especifica:

• Quais operações estão disponíveis
• Quais dados devem ser enviados
• Qual formato será utilizado
• Quais respostas podem ser retornadas
• Quais erros podem acontecer
• Como autenticação e autorização funcionam
• Quais limites e restrições precisam ser respeitados

Uma API não é apenas uma implementação técnica.

Ela representa um contrato entre consumidores e fornecedores.

Quando o contrato não está claro, os consumidores passam a depender de:

• Conversas informais
• Conhecimento individual
• Exemplos incompletos
• Testes manuais
• Tentativa e erro

Isso aumenta o risco de integrações incorretas e de mudanças inesperadas.

REST

REST é um estilo arquitetural muito utilizado para comunicação por HTTP.

Na analogia apresentada na aula, ele se aproxima de um menu executivo tradicional:

1. O cliente escolhe uma opção disponível.
2. Faz o pedido.
3. Aguarda o processamento.
4. Recebe uma resposta previamente definida.

Em uma API REST, o servidor normalmente define os recursos e os formatos das respostas.

Exemplo

GET /customers/123

Resposta:

{
  "id": 123,
  "name": "André",
  "email": "andre@example.com",
  "createdAt": "2026-07-28T10:00:00Z"
}

Vantagens

• Simplicidade conceitual
• Ampla adoção
• Compatibilidade com navegadores e ferramentas
• Facilidade de cache
• Boa integração com HTTP
• Grande quantidade de bibliotecas e documentação

Pontos de atenção

• Over-fetching
• Under-fetching
• Dificuldade de versionamento
• Dependência dos formatos de resposta
• Latência causada por múltiplas requisições

Over-fetching

A API retorna mais informações do que o consumidor realmente precisa.

No exemplo anterior, uma tela pode precisar apenas do nome, mas receber também e-mail e data de criação.

Under-fetching

O consumidor precisa realizar várias chamadas para obter todos os dados necessários.

GET /customers/123
GET /customers/123/orders
GET /customers/123/addresses

Cada chamada adicional pode aumentar a latência e a complexidade do fluxo.

GraphQL

GraphQL permite que o consumidor defina quais campos deseja receber.

A analogia apresentada na aula foi a de um bufê por quilo:

• O cliente escolhe exatamente os itens desejados.
• O servidor retorna os campos solicitados.

Exemplo

query {
  customer(id: 123) {
    name
    email
  }
}

Resposta conceitual:

{
  "data": {
    "customer": {
      "name": "André",
      "email": "andre@example.com"
    }
  }
}

Vantagens

• Redução de over-fetching
• Flexibilidade para consumidores
• Schema fortemente definido
• Introspecção do contrato
• Possibilidade de reunir dados de várias fontes
• Boa adequação a interfaces com necessidades diferentes

Pontos de atenção

• Consultas excessivamente complexas
• Dificuldade de cache HTTP tradicional
• Custo imprevisível de determinadas consultas
• Necessidade de limitar profundidade e quantidade de campos
• Risco de consultas N+1
• Maior complexidade de monitoramento
• Autorização por campo ou domínio

Consultas N+1

Uma consulta pode solicitar uma lista e, para cada item, provocar uma nova busca.

1 consulta para buscar clientes
+
N consultas para buscar os pedidos de cada cliente

Esse comportamento pode aumentar significativamente o custo da operação.

gRPC

gRPC é um framework de comunicação remota frequentemente utilizado entre serviços internos.

Na analogia da aula, ele funciona como uma linha direta entre a cozinha e o estoque.

Ele utiliza:

• HTTP/2
• Protocol Buffers
• Contratos fortemente tipados
• Serialização binária
• Comunicação eficiente

Exemplo de contrato

service CustomerService {
  rpc GetCustomer(GetCustomerRequest) returns (CustomerResponse);
}

Vantagens

• Alto desempenho
• Payloads compactos
• Contratos tipados
• Geração automática de clientes e servidores
• Suporte a streaming
• Boa adequação à comunicação entre serviços

Pontos de atenção

• Maior acoplamento ao contrato
• Testes manuais menos simples
• Payloads menos legíveis
• Necessidade de suporte adequado nos clientes
• Uso direto em navegadores mais complexo
• Evolução de contrato cuidadosamente controlada

Embora seja mais comum em back-end, existem alternativas como gRPC-Web para determinados cenários no front-end.

REST, GraphQL e gRPC

Não existe uma opção universalmente superior.

A escolha depende de:

• Tipo de consumidor
• Latência esperada
• Controle entre os times
• Flexibilidade das consultas
• Necessidade de cache
• Compatibilidade com navegadores
• Evolução do contrato

Latência como restrição física

Latência não é apenas um problema de código.

Uma chamada pode atravessar:

Dispositivo do cliente
↓
Rede local
↓
Internet
↓
Balanceadores
↓
Gateways
↓
Serviços
↓
Banco de dados
↓
APIs externas

Quanto maior a distância e o número de componentes, maior tende a ser o tempo de resposta.

Fontes de latência

• Distância geográfica
• Chamadas entre regiões
• Quantidade de serviços
• Consultas ao banco de dados
• Serialização
• Filas
• APIs externas
• Criptografia
• Processamento
• Congestionamento de rede
• Inicialização de funções serverless

Possíveis estratégias

• Aproximar servidores dos usuários
• Utilizar CDN
• Implementar cache
• Reduzir chamadas de rede
• Agrupar requisições
• Otimizar consultas
• Replicar dados
• Alterar a região da aplicação

Essas decisões podem aumentar:

• Custo de nuvem
• Complexidade
• Transferência de dados
• Duplicação de informações
• Problemas de consistência

Documentação como parte do contrato

Documentação não é um favor realizado pelo time que desenvolveu o sistema.

Ela faz parte do contrato arquitetural.

Uma documentação adequada permite compreender:

• Propósito da solução
• Componentes
• Fluxos principais
• Dependências
• Contratos
• Riscos
• Decisões tomadas
• Forma de integração
• Forma de operação

Sem documentação, os times passam a depender de conhecimento individual e comunicação informal.

Isso pode causar:

• Dependência entre equipes
• Retrabalho
• Integrações incorretas
• Dificuldade de evolução
• Riscos durante mudanças
• Concentração de conhecimento

Modelo C4

O modelo C4 documenta uma arquitetura em diferentes níveis de abstração.

Nível 1 — Contexto

Mostra:

• Sistema
• Usuários
• Sistemas externos
• Relações principais

Nível 2 — Contêineres

Mostra:

• Aplicações
• APIs
• Bancos
• Filas
• Componentes executáveis

Nesse contexto, contêiner não significa obrigatoriamente Docker.

Nível 3 — Componentes

Mostra os componentes internos de uma aplicação ou serviço.

Nível 4 — Código

Mostra classes, interfaces ou estruturas específicas quando necessário.

Contexto
↓
Contêineres
↓
Componentes
↓
Código

O modelo permite começar pela visão mais ampla do negócio e chegar progressivamente aos detalhes técnicos.

OpenAPI

OpenAPI é uma especificação para descrever APIs HTTP.

Ela pode documentar:

• Endpoints
• Métodos
• Parâmetros
• Autenticação
• Estruturas de requisição
• Estruturas de resposta
• Códigos de erro

O contrato pode ser utilizado para:

• Gerar documentação
• Criar clientes
• Criar mocks
• Validar requisições
• Automatizar testes
• Detectar incompatibilidades

Swagger

Swagger não é exatamente um sinônimo de OpenAPI.

Atualmente, Swagger representa um conjunto de ferramentas relacionadas à especificação OpenAPI.

Exemplos:

• Swagger UI
• Swagger Editor
• Swagger Codegen

AsyncAPI

AsyncAPI desempenha uma função semelhante à OpenAPI para arquiteturas assíncronas.

Ela pode documentar:

• Canais
• Tópicos
• Filas
• Eventos
• Produtores
• Consumidores
• Estruturas de mensagens
• Protocolos utilizados

Exemplo de evento

{
  "eventType": "PaymentApproved",
  "eventId": "abc-123",
  "occurredAt": "2026-07-28T14:00:00Z",
  "data": {
    "paymentId": "payment-01",
    "orderId": "order-55"
  }
}

Em sistemas orientados a eventos, o contrato precisa esclarecer:

• O que o evento representa
• Quando ele é publicado
• Quem pode consumi-lo
• Qual é sua estrutura
• Como evolui
• Como erros são tratados

Design-first e contract-first

Na abordagem design-first, também chamada de contract-first, o contrato é definido antes da implementação.

Fluxo possível

Negócio define a necessidade
↓
Times desenham o contrato
↓
Consumidores e produtores validam
↓
Mocks são disponibilizados
↓
Times desenvolvem em paralelo
↓
Testes verificam a implementação

Esse modelo reduz a dependência direta entre equipes.

Um consumidor pode iniciar o desenvolvimento utilizando o contrato e um mock, sem aguardar toda a implementação do fornecedor.

Plataformas de APIs

À medida que a quantidade de APIs cresce, torna-se necessário organizar:

• Catálogo
• Responsáveis
• Documentação
• Versões
• Dependências
• Domínios
• Indicadores de qualidade
• Padrões de segurança

Uma plataforma como o Backstage pode ser utilizada para construir um portal interno de desenvolvimento.

Ela pode reunir:

• Catálogo de serviços
• APIs
• Documentação
• Templates de projetos
• Responsáveis
• Dependências
• Links operacionais
• Indicadores de maturidade

O objetivo é reduzir fragmentação e facilitar a descoberta dos serviços existentes.

Mensageria e o mundo assíncrono

Na comunicação assíncrona, o produtor publica uma mensagem sem precisar aguardar o processamento final.

Exemplo de compra

Pedido é criado
↓
Evento é publicado
↓
Pagamento é processado
↓
Estoque é atualizado
↓
Transporte é solicitado
↓
Nota fiscal é emitida

Essas etapas podem acontecer de forma desacoplada.

Benefícios

• Absorção de picos
• Processamento em segundo plano
• Escalabilidade independente
• Menor acoplamento
• Maior resiliência
• Reprocessamento
• Integração com múltiplos consumidores

Desafios

• Consistência eventual
• Mensagens duplicadas
• Ordenação
• Idempotência
• Rastreamento distribuído
• Evolução de contratos
• Tratamento de falhas
• Dead-letter queues

Padrão Saga

O padrão Saga trata transações distribuídas como uma sequência de transações locais.

Na analogia apresentada na aula, uma viagem pode exigir:

1. Compra da passagem
2. Reserva do hotel
3. Aluguel do carro

Caso uma etapa falhe, pode ser necessário desfazer as etapas anteriores.

Essas ações são chamadas de transações compensatórias.

Exemplo

Criar pedido
↓
Reservar estoque
↓
Processar pagamento
↓
Solicitar entrega

Caso o pagamento falhe:

• Liberar o estoque
• Cancelar o pedido
• Cancelar o pagamento, quando aplicável

Saga orquestrada

Um componente central controla as etapas.

Vantagens

• Fluxo centralizado
• Maior visibilidade
• Regras explícitas
• Facilidade de compreender a sequência

Desvantagens

• Dependência do orquestrador
• Concentração de lógica
• Risco de um componente central excessivamente complexo

Saga coreografada

Cada serviço reage a eventos e publica novos eventos.

Vantagens

• Maior descentralização
• Menor dependência de um componente central
• Serviços mais autônomos

Desvantagens

• Fluxo difícil de visualizar
• Rastreamento mais complexo
• Dependências implícitas
• Depuração mais difícil

Limitação das compensações

Nem toda ação pode ser desfeita perfeitamente.

Um e-mail enviado não pode ser “desenviado”.

Nesse caso, a compensação pode exigir uma nova ação, como enviar uma correção.

CQRS

CQRS significa Command Query Responsibility Segregation.

O padrão separa:

• Operações de escrita, chamadas de commands
• Operações de leitura, chamadas de queries

O modelo utilizado para escrever não precisa ser o mesmo utilizado para ler.

Modelo de escrita

Pode priorizar:

• Regras de negócio
• Consistência
• Validações

Modelo de leitura

Pode priorizar:

• Velocidade
• Filtros
• Relatórios
• Consultas específicas

Vantagens

• Otimização independente de leitura e escrita
• Escalabilidade separada
• Modelos adequados a cada necessidade
• Bom suporte a domínios complexos

Desvantagens

• Maior complexidade
• Sincronização entre modelos
• Consistência eventual
• Mais componentes operacionais
• Depuração mais difícil

Event Sourcing

No Event Sourcing, o estado atual é derivado de uma sequência de eventos imutáveis.

Em vez de armazenar somente:

Saldo atual: R$ 500,00

o sistema pode armazenar:

Conta criada
Depósito de R$ 1.000,00
Pagamento de R$ 300,00
Saque de R$ 200,00

O estado atual é reconstruído a partir desses eventos.

Vantagens

• Histórico completo
• Auditoria
• Rastreabilidade
• Reconstrução de estados
• Novas projeções
• Análise temporal

Desvantagens

• Complexidade elevada
• Evolução de eventos
• Reprocessamento
• Grande volume de dados
• Necessidade de snapshots
• Curva de aprendizagem
• Exclusão e privacidade mais difíceis

Transactional Outbox

Transactional Outbox trata o problema de atualizar um banco de dados e publicar um evento de maneira confiável.

O problema

Uma aplicação precisa:

1. Salvar um pedido.
2. Publicar o evento OrderCreated.

Possível falha:

Pedido é salvo
↓
Publicação do evento falha
↓
Banco indica que o pedido existe
↓
Outros sistemas não recebem a informação

O estado entre banco e broker fica inconsistente.

A solução

Na mesma transação do banco, a aplicação grava:

• O dado de negócio
• Uma mensagem em uma tabela Outbox

Depois, outro processo lê a Outbox e publica a mensagem.

Aplicação
↓
Transação no banco
├── Salva pedido
└── Salva evento na Outbox
          ↓
Publicador ou CDC
          ↓
Broker

Vantagens

• Reduz inconsistência entre banco e broker
• Não exige transação distribuída entre plataformas
• Permite reprocessamento
• Melhora a confiabilidade da publicação

Pontos de atenção

• Mensagens podem ser publicadas mais de uma vez
• Consumidores precisam ser idempotentes
• A tabela Outbox precisa ser monitorada
• Registros precisam ser limpos
• Atrasos de publicação precisam ser acompanhados

Observabilidade

Observabilidade é a capacidade de compreender o estado interno do sistema por meio dos sinais produzidos por ele.

Seus três pilares tradicionais são:

• Logs
• Métricas
• Traces

Ter dados de observabilidade não é suficiente.

Eles precisam ser analisados e utilizados.

Logs

Logs registram eventos ocorridos na aplicação.

Eles podem mostrar:

• Sucessos
• Erros
• Mudanças de estado
• Integrações
• Decisões
• Tentativas de acesso
• Eventos de segurança

Logs estruturados

Um log estruturado utiliza campos consistentes.

{
  "level": "ERROR",
  "service": "payment-service",
  "correlationId": "corr-123",
  "orderId": "order-55",
  "message": "Payment provider timeout",
  "timestamp": "2026-07-28T14:10:00Z"
}

Isso facilita:

• Pesquisa
• Correlação
• Criação de alertas
• Auditoria
• Processamento automatizado

Dados que não devem aparecer

• Senhas
• Tokens
• Dados bancários
• Dados pessoais desnecessários
• Segredos de infraestrutura

Métricas

Métricas representam valores numéricos ao longo do tempo.

Métricas técnicas

• Uso de CPU
• Uso de memória
• Tempo de resposta
• Taxa de erros
• Quantidade de requisições
• Profundidade de filas
• Disponibilidade

Métricas de negócio

• Pedidos criados
• Pagamentos aprovados
• Carrinhos abandonados
• Usuários ativos
• Conversão
• Receita
• Cancelamentos

As métricas devem mostrar não apenas se a aplicação está funcionando tecnicamente, mas se o negócio está operando corretamente.

Testes A/B também podem utilizar métricas para comparar comportamentos e avaliar resultados.

Distributed Tracing

Distributed Tracing acompanha uma operação por vários serviços.

Front-end
↓
API Gateway
↓
Serviço de pedidos
↓
Serviço de pagamento
↓
Provedor externo

Cada etapa gera um span associado ao mesmo trace.

Isso permite identificar:

• Onde ocorreu uma falha
• Qual serviço está lento
• Quanto tempo cada etapa consumiu
• Qual dependência causou o problema

Um identificador de correlação precisa acompanhar a operação pelos componentes.

Sistemas legados exigem respeito

Modernizar um sistema legado não significa simplesmente descartá-lo.

O sistema pode conter:

• Regras construídas ao longo de anos
• Conhecimento não documentado
• Integrações críticas
• Processos regulatórios
• Dependências de outras áreas
• Dados históricos
• Operações essenciais para a empresa

A modernização precisa reduzir riscos e preservar o funcionamento do negócio.

Por isso, arquiteturas transitórias podem ser utilizadas durante a modernização.

Strangler Fig Pattern

Strangler Fig moderniza um sistema gradualmente.

A nova arquitetura cresce ao redor do legado e assume suas funcionalidades aos poucos.

Processo

Legado continua funcionando
↓
Funcionalidade é implementada no novo sistema
↓
Tráfego é redirecionado
↓
Funcionalidade antiga é desativada
↓
Processo é repetido

Vantagens

• Migração incremental
• Redução de risco
• Entrega contínua de valor
• Adoção gradual de tecnologias
• Possibilidade de retorno ao fluxo anterior

Pontos de atenção

• Dois sistemas em operação
• Gerenciamento de rotas
• Contratos entre arquiteturas
• Duplicação ou sincronização de dados
• Maior custo temporário
• Monitoramento de ambientes diferentes

Anti-Corruption Layer

A Anti-Corruption Layer, ou ACL, protege o domínio do novo sistema contra modelos e conceitos do legado.

Novo sistema
↕
Anti-Corruption Layer
↕
Sistema legado

A ACL pode:

• Converter modelos
• Traduzir nomenclaturas
• Adaptar protocolos
• Mapear erros
• Proteger as regras do novo domínio

Vantagens

• Preserva o novo modelo de domínio
• Reduz acoplamento ao legado
• Facilita migração progressiva
• Melhora testabilidade
• Evita contaminação conceitual

Pontos de atenção

• Complexidade adicional
• Mais processamento
• Latência
• Duplicação de modelos
• Risco de permanência da camada temporária
• Manutenção dos tradutores

Change Data Capture

Change Data Capture, ou CDC, captura alterações realizadas em um banco de dados e as propaga para outros destinos.

As mudanças podem ser obtidas por:

• Logs do banco
• Transaction logs
• Binlogs
• Change streams
• Triggers, em determinados cenários

Possíveis destinos

• Outro banco
• Data lake
• Mecanismo de busca
• Microsserviço
• Kafka
• Plataforma analítica

Vantagens

• Captura quase em tempo real
• Baixo impacto na aplicação de origem
• Integração com legados
• Replicação de dados
• Alimentação de eventos
• Apoio a migrações

Pontos de atenção

• Evolução de schema
• Ordenação
• Duplicações
• Latência entre origem e destino
• Acoplamento ao modelo da origem
• Tratamento de exclusões
• Monitoramento
• Exposição de detalhes internos do banco

Parallel Run

No Parallel Run, a mesma operação é processada pelo sistema antigo e pelo novo.

Os resultados são comparados para verificar:

• Compatibilidade
• Divergências
• Desempenho
• Regras de negócio
• Erros ocultos

Normalmente, apenas a resposta do sistema atual é apresentada ao usuário.

Requisição real
├── Sistema antigo → resposta utilizada
└── Sistema novo → resposta comparada

Dark Launch

No Dark Launch, a nova funcionalidade recebe tráfego real ou uma cópia do tráfego, mas seus resultados ainda não afetam a experiência final.

Vantagens

• Validação com carga real
• Descoberta de comportamentos inesperados
• Comparação de resultados
• Redução do risco
• Coleta de métricas antes do lançamento

Pontos de atenção

• Duplicação de processamento
• Custo de infraestrutura
• Proteção de dados
• Efeitos colaterais duplicados
• Sincronização
• Comparação de resultados
• Risco de cobranças ou notificações duplicadas

Combinando padrões transitórios

Uma modernização pode combinar:

• Strangler Fig para migração gradual
• ACL para proteção do novo domínio
• CDC para sincronização de dados
• Parallel Run para comparação
• Dark Launch para validação com tráfego real
• Outbox para publicação confiável de eventos

Exemplo conceitual:

Strangler Fig direciona a migração
↓
ACL traduz conceitos do legado
↓
CDC sincroniza alterações
↓
Outbox publica eventos
↓
Parallel Run compara resultados
↓
Dark Launch valida com tráfego real

Essas soluções são transitórias porque apoiam a passagem entre a arquitetura antiga e a nova.

Entretanto, uma solução temporária sem prazo, responsável e critério de encerramento pode se tornar uma dependência permanente.

Spec-Driven Development e inteligência artificial

O termo correto registrado nas anotações é SDD — Spec-Driven Development.

Na abordagem orientada por especificações, o time descreve claramente:

• Requisitos
• Restrições
• Contratos
• Critérios de aceitação
• Casos de uso
• Requisitos não funcionais
• Decisões arquiteturais

A inteligência artificial pode utilizar essas especificações para:

• Gerar protótipos
• Criar contratos
• Implementar alternativas
• Produzir testes
• Simular padrões
• Comparar abordagens
• Acelerar provas de conceito

A IA pode produzir várias alternativas rapidamente.

O arquiteto, entretanto, continua responsável por avaliar:

• Qual alternativa resolve o problema real
• Qual respeita as restrições
• Qual o time consegue operar
• Qual apresenta melhor relação entre custo e benefício
• Qual reduz riscos sem criar complexidade desnecessária

Checklist para sistemas integrados

Antes de definir uma integração, pergunte:

Contrato

• O contrato está documentado?
• Erros e restrições estão claros?
• A evolução será compatível?
• Consumidores conseguem utilizar mocks?

Comunicação

• A resposta precisa ser imediata?
• O processo pode ser assíncrono?
• Qual é a latência aceitável?
• Existem riscos de indisponibilidade?

Mensageria

• Como duplicações serão tratadas?
• A ordem é importante?
• Consumidores são idempotentes?
• Existe dead-letter queue?
• O fluxo possui rastreabilidade?

Observabilidade

• Existem logs estruturados?
• Métricas técnicas e de negócio estão definidas?
• Há tracing distribuído?
• O correlation ID atravessa todo o fluxo?

Modernização

• O legado pode ser substituído gradualmente?
• É necessário proteger o novo domínio?
• Os dados precisam ser sincronizados?
• Resultados podem ser comparados antes da migração?

Conclusão

Arquitetura de software, na prática, envolve decisões sobre:

• Comunicação
• Contratos
• Operação
• Evolução
• Risco

REST, GraphQL e gRPC atendem necessidades diferentes.

OpenAPI e AsyncAPI tornam contratos legíveis por pessoas e ferramentas.

Mensageria permite processamento assíncrono, desacoplamento e absorção de picos, mas exige decisões sobre consistência, idempotência e rastreamento.

Saga, CQRS, Event Sourcing e Transactional Outbox tratam problemas específicos de sistemas distribuídos e não devem ser adotados sem necessidade concreta.

Observabilidade depende de logs, métricas e traces que sejam realmente utilizados.

Sistemas legados precisam ser modernizados com controle de risco, respeitando regras, dados e processos essenciais para o negócio.

Strangler Fig, ACL, CDC, Parallel Run e Dark Launch criam caminhos mais seguros para essa evolução.

Arquitetar sistemas integrados significa definir contratos confiáveis, observar o comportamento da solução e criar caminhos seguros para que ela evolua sem interromper o negócio.