Principais pontos
- A transição foi conduzida por meio de um desacoplamento gradual, sem substituir totalmente o sistema existente.
- Um sistema de dados em tempo real baseado em CDC substituiu o acesso direto ao mainframe.
- Em vez de REST, o uso de GraphQL eliminou várias camadas de BFF e garantiu flexibilidade e facilidade de manutenção.
- Uma estrutura de equipes centrada em domínio (
Team Topologies) deixou mais claras as responsabilidades e a propriedade de cada time. - Com deploy gradual e automação, o sistema foi migrado sem risco e com entrega estável de valor.
Caso de adoção: metade do sistema sobreviveu mesmo durante uma falha
Houve uma falha no mainframe, mas a nova UI continuou funcionando normalmente graças à arquitetura de streaming baseada em nuvem.
Mesmo com o sistema legado fora do ar, o novo sistema manteve a experiência do cliente e comprovou sua resiliência.
Estratégia principal: desacoplamento em múltiplas camadas
- Domain-Driven Design (DDD): reestruturar o modelo centrado no mainframe para um formato mais alinhado ao negócio
- Team Topologies: migrar para uma organização de equipes orientada por capacidades
- Arquitetura orientada a eventos: reduzir o acoplamento entre sistemas de forma assíncrona
- Change Data Capture (CDC): detectar mudanças de dados em tempo real para conectar o legado ao novo sistema
Estrutura anterior: Unified Web Portal 1.0
Diversos dados do mainframe eram integrados via ETL e disponibilizados em SQL DB e SaaS,
mas surgiram problemas como falta de tempo real, queda na qualidade dos dados e chamadas diretas ao mainframe.
Problemas
- Atraso de dados causado pelo ETL
- Conexão síncrona com o mainframe sem elasticidade
- Criação de um número enorme de APIs BFF
- Gargalos e atrasos de release causados pela estrutura organizacional
- Em picos de tráfego, a sobrecarga no mainframe derrubava todo o serviço
Definição de novos objetivos
Objetivos técnicos: desacoplar mainframe e web, eliminar o BFF e garantir autonomia dos times
Objetivos de negócio: reduzir contatos no call center, cortar custos de licença e melhorar a satisfação do cliente
Visão geral da nova arquitetura
- O mainframe continua sendo o system of record
- CDC → Kafka → banco de dados de domínio (CosmosDB)
- GraphQL + REST API → BFF → UI
- Todos os componentes são conectados por uma estrutura orientada a eventos e um message broker
Etapa 1: Change Data Capture
- Construção de um system of reference com streaming de dados em tempo real
- Mainframe → Kafka → transformação → banco de dados de domínio → disponibilização por API
- Estrutura de dados flexível, sem dependência do schema do mainframe
Etapa 2: Domain-Driven Design + GraphQL
- Definição do modelo de domínio com DDD (
Entity,Command,Event) - Cada domínio é organizado como um nó GraphQL, com geração de um supergraph via schema stitching
- Suporte a uma estrutura de consultas otimizada, buscando apenas os dados necessários
Mudança na estrutura organizacional: Team Topologies
- Reorganização em stream-aligned teams orientados por capacidades
- Áreas complexas (ex.: integração com mainframe) são gerenciadas por equipes dedicadas
- Operação de um time de enablement para suporte técnico
Expansão orientada a eventos: eventos internos de domínio + padrão Saga
- O padrão Outbox gera eventos quando há mudanças no domínio
- Uma Parallel Saga sincroniza o processamento do mainframe com o CDC
- Construção de workflows baseados em máquina de estados → compatível também com fluxos complexos
Desafios
- Foi necessário mudar a percepção interna da organização sobre a adoção de uma arquitetura orientada a eventos
- Em uma estrutura assíncrona, garantir observabilidade é essencial
- Jobs em batch do mainframe → provocam sobrecarga no pipeline de CDC
- Complexidade de gerenciamento do schema GraphQL e discussão sobre adoção de uma abordagem federada
- Interesses transversais, como autenticação e logging, são gerenciados com pacotes separados e automação
Estratégia de release: release train + Feature Flag
- Cada time faz deploy de forma independente, com integração no repositório de deploy
- O pipeline de deploy por ambiente é estruturado com Kustomize
- Feature flags separam releases de funcionalidade e segurança, mantendo o desenvolvimento trunk-based
Aplicação de arquitetura híbrida
- UWP 1.0 e UWP 2.0 coexistiram durante a transição gradual
- O roteamento na borda migrou gradualmente as requisições dos usuários para o novo sistema
Conclusão: construção de uma plataforma evolutiva
- Desacoplamento completo entre frontend e mainframe
- Estrutura centrada em times para garantir velocidade e estabilidade
- Melhoria na satisfação do cliente e nos custos operacionais
- Base flexível que viabiliza até mesmo a futura substituição do mainframe
1 comentários
A melhoria gradual e a extração progressiva de microsserviços são muito importantes... quando vejo textos assim, sinto que o PM que lidera esse projeto é realmente muito importante e impressionante. Gerenciar tudo isso é tenso demais, haha