{"configuration":{},"description":"Arquitetura para consolidação de dados de cliente/colaborador com melhorias recomendadas","documentation":{"decisions":[{"content":"# 1. Adoção de Arquitetura Hexagonal/DDD/Clean\n\nDate: 2025-12-01\n\n## Status\n\nAccepted\n\n## Context\n\nA solução precisa permitir evolução e testabilidade, bem como separar regras de negócio da infraestrutura. Há múltiplos sistemas de origem (CRM e legados), e a consulta deve ser exposta por API sem acoplamento com esses sistemas. Queremos permitir substituição de tecnologias sem impactar o domínio.\n\nA complexidade do domínio de cliente (múltiplas fontes de dados, regras de priorização, reconciliação) exige uma arquitetura que mantenha o código de negócio isolado e testável.\n\n## Decision\n\nAdotar **Arquitetura Hexagonal** com princípios de **Domain-Driven Design (DDD)** e **Clean Architecture**. \n\nOs microsserviços serão estruturados em camadas bem definidas:\n\n- **Domain** (agregados, entidades, value objects): Contém as regras de negócio puras, sem dependências de frameworks ou infraestrutura.\n- **Application** (casos de uso, orquestração): Orquestra a execução de regras de negócio e coordena interações entre domínio e adaptadores.\n- **Adapters** (inbound: controllers REST; outbound: repositories, produtores Kafka): Implementam as interfaces definidas pelo domínio para comunicação com o mundo externo.\n\nO domínio \"Cliente\" possui agregados (CustomerProfile) e serviços de aplicação (CustomerQueryService, ProfileMergerService). Os adaptadores de entrada (REST controllers, Kafka listeners) e saída (repositórios, produtores de eventos) são plugáveis.\n\n## Alternatives Considered\n\n### 1. Arquitetura em Camadas Tradicional (3-tier)\n**Descrição:** Separação simples em controller/service/repository.\n\n**Prós:**\n- Mais fácil de entender inicialmente\n- Menos código boilerplate\n- Familiaridade da equipe\n\n**Contras:**\n- Mistura regras de negócio com detalhes de tecnologia\n- Dificulta testes unitários isolados\n- Alto acoplamento entre camadas\n- Difícil evolução e substituição de tecnologias\n\n**Por que foi descartada:** Não atende aos requisitos de testabilidade e evolução independente.\n\n### 2. Monólito Modular\n**Descrição:** Agrupar todos os componentes num único deploy com módulos bem definidos.\n\n**Prós:**\n- Facilita consistência transacional\n- Menos complexidade operacional\n- Deploy único\n\n**Contras:**\n- Prejudica escalabilidade independente\n- Contraria a premissa de microsserviços\n- Acoplamento de deploy entre módulos\n\n**Por que foi descartada:** Não permite escalar componentes de leitura e escrita independentemente (CQRS).\n\n## Consequences\n\n**Positivas:**\n- Mudanças nos adaptadores (ex: trocar Kafka por RabbitMQ) não impactam o domínio\n- Facilita testes unitários, pois o núcleo não depende de frameworks\n- Reduz acoplamento de longo prazo e melhora a manutenibilidade\n- Permite evolução independente de cada camada\n\n**Negativas:**\n- Introduz alguma complexidade inicial\n- Exige disciplina na definição de agregados e casos de uso\n- Curva de aprendizado para desenvolvedores não familiarizados com DDD\n\n**Componentes Afetados:**\n- Customer Query Service (BFF)\n- Consolidador de Dados\n","date":"2025-12-01T05:00:00Z","format":"Markdown","id":"1","status":"Accepted","title":"Adoção de Arquitetura Hexagonal/DDD/Clean"},{"content":"# 10. Uso de TM Forum OpenAPIs\n\nDate: 2025-12-01\n\n## Status\n\nAccepted\n\n## Context\n\nA solução deve estar alinhada às boas práticas de APIs do setor de telecom. O TM Forum define um conjunto de OpenAPIs padronizadas para domínios como Cliente, Parte, Conta e Atendimento.\n\n## Decision\n\nAdotar as OpenAPIs **TMF629 – Customer Management** e **TMF632 – Party Management** como base para modelar as APIs de consulta. Essas APIs guiam a estrutura de recursos, URIs e payloads. Eventos são mapeados para eventos de domínio e publicados no Event Bus.\n\n## Consequences\n\nA aderência às OpenAPIs do TM Forum facilita integração com parceiros e reduz atrito em projetos de eSIM, portabilidade e faturamento. Exige disciplina em seguir especificações.\n\n**Componentes Afetados:**\n- API Gateway\n- Customer Query Service (BFF)\n- Schema Registry\n\n## Alternatives Considered\n\n### 1. Modelos Proprietários\n**Descrição:** Modelos definidos internamente pela Telefônica.\n\n**Prós:**\n- Total controle sobre estrutura\n- Adaptado às necessidades específicas\n- Sem restrições de padrões\n\n**Contras:**\n- Menos interoperáveis com parceiros\n- Reinventar a roda\n- Dificuldade em integrações externas\n\n**Por que foi descartada:** Menor interoperabilidade e alinhamento com indústria.\n\n### 2. Outras Iniciativas TM Forum (TMF620 – Product Catalog)\n**Descrição:** APIs do TM Forum focadas em catálogo de produtos.\n\n**Prós:**\n- Padrão da indústria\n- Bem documentado\n\n**Contras:**\n- Aplicável a produtos, não a dados de cliente\n- Escopo diferente\n\n**Por que foi descartada:** Não se aplica ao domínio de cliente.\n","date":"2025-12-01T05:00:00Z","format":"Markdown","id":"10","status":"Accepted","title":"Uso de TM Forum OpenAPIs"},{"content":"# 11. Versionamento de Eventos: Schema Registry\n\nDate: 2025-12-01\n\n## Status\n\nAccepted\n\n## Context\n\nOs eventos publicados no Kafka evoluem ao longo do tempo. Adicionar ou remover campos pode quebrar consumidores que não estão preparados para essas mudanças.\n\n## Decision\n\nAdotar um **Schema Registry** (Confluent Schema Registry ou Apicurio Registry) para armazenar e validar schemas de eventos. Produtores registram schemas antes de publicar eventos. Consumidores validam eventos contra schemas esperados. O Schema Registry suporta evolução de schemas com compatibilidade backward, forward e full.\n\n## Consequences\n\nO Schema Registry adiciona uma dependência operacional, mas previne quebras de compatibilidade e facilita a evolução independente de serviços.\n\n**Componentes Afetados:**\n- Schema Registry\n- Conectores (CRM e Legados)\n- Consolidador de Dados\n\n## Alternatives Considered\n\n### 1. Sem Versionamento Explícito\n**Descrição:** Produtores e consumidores acordam schemas informalmente.\n\n**Prós:**\n- Simplicidade inicial\n- Sem dependências adicionais\n\n**Contras:**\n- Alto risco de quebras acidentais\n- Sem validação automática\n- Evolução caótica\n\n**Por que foi descartada:** Risco inaceitável de quebras em produção.\n\n### 2. Versionamento Manual via Tópicos Separados\n**Descrição:** Criar tópico novo para cada versão (ex: `customer-updated-v1`, `customer-updated-v2`).\n\n**Prós:**\n- Isolamento completo entre versões\n- Sem conflitos\n\n**Contras:**\n- Fragmenta os dados\n- Dificulta migração\n- Overhead operacional\n\n**Por que foi descartada:** Complexidade operacional e fragmentação.\n","date":"2025-12-01T05:00:00Z","format":"Markdown","id":"11","status":"Accepted","title":"Versionamento de Eventos: Schema Registry"},{"content":"# 12. Feature Flags para Controle de Rollout\n\nDate: 2025-12-01\n\n## Status\n\nAccepted\n\n## Context\n\nNovas funcionalidades e regras de negócio precisam ser testadas em produção com um subconjunto de usuários antes de serem liberadas para todos. É necessário ter a capacidade de desabilitar funcionalidades problemáticas instantaneamente sem fazer um novo deploy.\n\n## Decision\n\nIntegrar uma plataforma de **Feature Flags** (LaunchDarkly, Unleash ou ConfigCat) no Customer Query Service e no Consolidador. Flags podem ser controladas por percentual de usuários, região geográfica, tipo de plano, ou qualquer outro atributo. Isso permite **Canary Releases** e **A/B testing**.\n\n## Consequences\n\nFeature Flags adicionam uma dependência externa, mas oferecem controle fino sobre o comportamento da aplicação em tempo de execução. Facilitam a experimentação e reduzem o risco de rollouts.\n\n**Componentes Afetados:**\n- Feature Flag Service\n- Customer Query Service (BFF)\n- Consolidador de Dados\n\n## Alternatives Considered\n\n### 1. Configuração Estática (application.properties)\n**Descrição:** Flags definidas em arquivos de configuração.\n\n**Prós:**\n- Simples de implementar\n- Sem dependências externas\n\n**Contras:**\n- Requer redeploy para mudar flags\n- Sem controle granular por usuário\n- Sem interface de gestão\n\n**Por que foi descartada:** Não permite controle dinâmico em produção.\n\n### 2. Feature Flags Customizados (Implementação Própria)\n**Descrição:** Desenvolver sistema próprio de feature flags.\n\n**Prós:**\n- Total controle\n- Sem custo de licença\n\n**Contras:**\n- Esforço de desenvolvimento\n- Manutenção contínua\n- Menos features que soluções prontas\n\n**Por que foi descartada:** Reinventar a roda com menor maturidade.\n","date":"2025-12-01T05:00:00Z","format":"Markdown","id":"12","status":"Accepted","title":"Feature Flags para Controle de Rollout"},{"content":"# 13. Chaos Engineering para Validação de Resiliência\n\nDate: 2025-12-01\n\n## Status\n\nAccepted\n\n## Context\n\nOs padrões de resiliência (Circuit Breaker, Retry, etc.) precisam ser validados em condições reais de falha. Testes em ambientes controlados podem não revelar todos os problemas.\n\n## Decision\n\nImplementar práticas de **Chaos Engineering** usando ferramentas como **Gremlin** ou **LitmusChaos**. Injetar falhas controladas em produção (derrubar pods, introduzir latência, simular indisponibilidade de Kafka) e monitorar como o sistema se comporta e se recupera.\n\n## Consequences\n\nChaos Engineering exige maturidade operacional e monitoramento robusto, mas identifica proativamente pontos fracos e aumenta a confiança na arquitetura.\n\n**Componentes Afetados:**\n- Chaos Engineering Tool\n- Todos os microsserviços\n\n## Alternatives Considered\n\n### 1. Apenas Testes de Carga\n**Descrição:** Validar performance sem injeção de falhas.\n\n**Prós:**\n- Simples de implementar\n- Valida performance sob carga\n\n**Contras:**\n- Não valida resiliência sob falhas\n- Não identifica pontos fracos\n- Falso senso de segurança\n\n**Por que foi descartada:** Não valida comportamento sob falhas reais.\n\n### 2. Testes Manuais de Falha\n**Descrição:** Derrubar serviços manualmente para testar resiliência.\n\n**Prós:**\n- Controle total\n- Sem ferramentas adicionais\n\n**Contras:**\n- Menos frequentes\n- Não cobrem todos os cenários\n- Difícil de repetir consistentemente\n\n**Por que foi descartada:** Cobertura insuficiente e baixa frequência.\n","date":"2025-12-01T05:00:00Z","format":"Markdown","id":"13","status":"Accepted","title":"Chaos Engineering para Validação de Resiliência"},{"content":"# 14. Gestão de Segredos: Secrets Manager\n\nDate: 2025-12-01\n\n## Status\n\nAccepted\n\n## Context\n\nA aplicação precisa acessar chaves de criptografia, senhas de banco de dados e tokens de API. Armazenar esses segredos em código ou configurações é inseguro e viola as melhores práticas de segurança.\n\n## Decision\n\nUtilizar um **Secrets Manager** (HashiCorp Vault ou Azure Key Vault) para gerenciar segredos de forma centralizada e segura. Aplicações solicitam segredos em tempo de execução, e o Secrets Manager controla o acesso através de políticas de autorização. Chaves de criptografia são rotacionadas automaticamente.\n\n## Consequences\n\nO Secrets Manager adiciona uma dependência operacional, mas garante que segredos nunca sejam expostos em código ou logs. Facilita a conformidade com requisitos de segurança e auditoria.\n\n**Componentes Afetados:**\n- Secrets Manager\n- Customer Query Service (BFF)\n- Consolidador de Dados\n\n## Alternatives Considered\n\n### 1. Variáveis de Ambiente\n**Descrição:** Armazenar segredos em variáveis de ambiente.\n\n**Prós:**\n- Simples de implementar\n- Suporte nativo em todas as plataformas\n\n**Contras:**\n- Menos seguras (podem vazar em logs)\n- Difíceis de rotacionar\n- Sem auditoria de acesso\n\n**Por que foi descartada:** Segurança insuficiente e falta de auditoria.\n\n### 2. ConfigMaps do Kubernetes\n**Descrição:** Usar ConfigMaps para armazenar segredos.\n\n**Prós:**\n- Nativo do Kubernetes\n- Fácil integração\n\n**Contras:**\n- Não são criptografados por padrão\n- Sem auditoria de acesso\n- Menos seguro que Secrets Manager dedicado\n\n**Por que foi descartada:** Segurança e auditoria insuficientes.\n","date":"2025-12-01T05:00:00Z","format":"Markdown","id":"14","status":"Accepted","title":"Gestão de Segredos: Secrets Manager"},{"content":"# 2. Linguagem e Plataforma: Java + Spring Boot\n\nDate: 2025-12-01\n\n## Status\n\nAccepted\n\n## Context\n\nA Telefônica tem grande base instalada em Java e experiência com Spring. É necessário suporte a frameworks de integração (REST, SOAP), mensageria e observabilidade. A solução deve ter amplo ecossistema e produtividade.\n\nA equipe de desenvolvimento possui expertise em Java e a infraestrutura corporativa já está otimizada para aplicações JVM.\n\n## Decision\n\nUtilizar **Java 17** com **Spring Boot 3** como plataforma padrão dos microsserviços. \n\nO Spring oferece módulos para:\n- WebFlux (REST reativo)\n- Spring Data para bancos\n- Spring Kafka/RabbitMQ\n- Spring Security e integração com OAuth2/OIDC\n\nO uso de **Maven** no build e **JUnit** para testes será padrão.\n\n## Consequences\n\n**Positivas:**\n- Aderência à plataforma existente\n- Reuso de bibliotecas corporativas\n- Facilidade de contratação de profissionais\n- Ecossistema maduro e bem documentado\n- Suporte a padrões corporativos (SOAP, REST, mensageria)\n\n**Negativas:**\n- Maior consumo de recursos em comparação com Go ou Node.js\n- Tempo de startup mais lento (mitigado com GraalVM Native Image)\n- Footprint de memória maior\n\n**Mitigações:**\n- Uso de GraalVM para reduzir consumo de memória\n- Ajustes de performance e tuning de JVM\n- Containerização otimizada com imagens base slim\n\n**Componentes Afetados:**\n- Todos os microsserviços (BFF, Consolidador, Conectores)\n\n## Alternatives Considered\n\n### 1. Node.js/TypeScript\n**Descrição:** Plataforma JavaScript/TypeScript para backend.\n\n**Prós:**\n- Maior produtividade para desenvolvedores full-stack\n- Ecossistema NPM rico\n- Performance adequada para I/O-bound\n\n**Contras:**\n- Menos maturidade em integrações SOAP/legado\n- Latência de garbage collection menos previsível\n- Menor adequação à cultura corporativa Java da Vivo\n\n**Por que foi descartada:** Menor aderência à base instalada e expertise da equipe.\n\n### 2. Golang (Go)\n**Descrição:** Linguagem compilada focada em performance e concorrência.\n\n**Prós:**\n- Performance superior e footprint reduzido\n- Concorrência nativa (goroutines)\n- Binários standalone\n\n**Contras:**\n- Ecossistema de frameworks de negócio menor\n- Curva de aprendizado maior para a equipe\n- Menos bibliotecas para integrações corporativas\n\n**Por que foi descartada:** Curva de aprendizado e menor maturidade no ecossistema corporativo.\n","date":"2025-12-01T05:00:00Z","format":"Markdown","id":"2","status":"Accepted","title":"Linguagem e Plataforma: Java + Spring Boot"},{"content":"# 3. Mensageria: Kafka como Event Bus\n\nDate: 2025-12-01\n\n## Status\n\nAccepted\n\n## Context\n\nÉ necessário distribuir eventos de alteração de dados com alta vazão, retenção persistente, escalabilidade horizontal e garantia de ordem. O serviço deve suportar picos de atendimento e desacoplar produtores de consumidores.\n\nO volume esperado é de milhões de eventos por dia, com necessidade de reprocessamento e auditoria.\n\n## Decision\n\nAdotar **Apache Kafka** como **Event Bus** para os domínios de cliente. \n\nKafka oferece:\n- Latências de poucos milissegundos\n- Suporte a clusters com milhares de brokers\n- Processamento de trilhões de mensagens por dia\n- Retenção de eventos configurável\n- Partições para escalabilidade\n- Processamento \"exactly-once\"\n\nOs conectores e o consolidador utilizam **Spring Kafka** para produzir/consumir eventos.\n\n## Consequences\n\n**Positivas:**\n- Escalabilidade e performance superiores\n- Retenção de eventos possibilita reprocessamento e auditoria\n- Desacoplamento total entre produtores e consumidores\n- Garantia de ordem dentro de uma partição\n- Suporte a múltiplos consumidores independentes\n\n**Negativas:**\n- Aprendizado para gerenciamento de clusters\n- Requer monitoramento especializado (zookeeper/Kraft)\n- Complexidade operacional maior que message brokers tradicionais\n\n**Componentes Afetados:**\n- Event Bus\n- Conectores (CRM e Legados)\n- Consolidador de Dados\n- Schema Registry\n\n## Alternatives Considered\n\n### 1. RabbitMQ\n**Descrição:** Broker de mensagens robusto com suporte a múltiplos protocolos.\n\n**Prós:**\n- Excelente para filas de trabalho\n- Roteamento flexível (exchanges, bindings)\n- Maturidade e estabilidade\n\n**Contras:**\n- Menos eficiente para streaming de eventos de alto volume\n- Retenção de mensagens limitada\n- Escalabilidade horizontal mais complexa\n\n**Por que foi descartada:** Não é otimizado para streaming de eventos de alto volume.\n\n### 2. Azure Event Hubs\n**Descrição:** Serviço PaaS de streaming de eventos da Microsoft.\n\n**Prós:**\n- Gerenciamento simplificado (PaaS)\n- Integração nativa com Azure\n- Sem overhead operacional\n\n**Contras:**\n- Vendor lock-in (dependência de provedor específico)\n- Limita personalização de retenção\n- Custo potencialmente mais alto\n\n**Por que foi descartada:** Dependência de provedor e menor flexibilidade.\n","date":"2025-12-01T05:00:00Z","format":"Markdown","id":"3","status":"Accepted","title":"Mensageria: Kafka como Event Bus"},{"content":"# 4. Read Model e Banco de Dados: MongoDB/Cassandra + Redis\n\nDate: 2025-12-01\n\n## Status\n\nAccepted\n\n## Context\n\nA API de consulta precisa responder em milissegundos. O volume de clientes é alto e há necessidade de consultas flexíveis (por CPF, nome, telefone). O banco deve suportar escrita assíncrona via consolidador e leitura altamente escalável.\n\n## Decision\n\nUtilizar uma combinação de **MongoDB** ou **Apache Cassandra** como banco de dados do **Customer Profile Store**, com **Redis** como cache distribuído (L1). MongoDB/Cassandra são bancos NoSQL que oferecem leitura rápida, escalabilidade horizontal e modelo de documentos/colunas flexível. Redis fornece cache in-memory replicado para reduzir latência. Adicionalmente, cada instância do BFF possui um **cache local (L2) com Caffeine**.\n\n## Consequences\n\nO uso de MongoDB/Cassandra com Redis permite consultas rápidas e escalabilidade linear. A consistência é eventual; o read model pode estar desatualizado durante alguns segundos após uma alteração. O cache L2 reduz ainda mais a latência para perfis \"quentes\", atingindo latências sub-milissegundo.\n\n**Componentes Afetados:**\n- Customer Profile Store\n- Customer Query Service (BFF)\n- Consolidador de Dados\n\n## Alternatives Considered\n\n### 1. PostgreSQL (Relacional)\n**Descrição:** Banco de dados relacional ACID completo.\n\n**Prós:**\n- Conhecido e maduro\n- ACID completo\n- Consultas SQL complexas\n\n**Contras:**\n- Escalabilidade horizontal limitada\n- Latência maior para consultas complexas\n- Schema rígido\n\n**Por que foi descartada:** Escalabilidade horizontal limitada e latência maior.\n\n### 2. ElasticSearch\n**Descrição:** Motor de busca e analytics distribuído.\n\n**Prós:**\n- Excelente para buscas de texto\n- Agregações poderosas\n- Escalabilidade horizontal\n\n**Contras:**\n- Menos adequado para consistência de dados complexos\n- Exigiria pipeline de indexação adicional\n- Overhead de sincronização\n\n**Por que foi descartada:** Não é otimizado para armazenamento primário de dados estruturados.\n\n### 3. Event Sourcing Pleno\n**Descrição:** Armazenar apenas eventos e reconstruir estado em tempo real.\n\n**Prós:**\n- Auditabilidade completa\n- Escalabilidade teórica\n- Histórico completo\n\n**Contras:**\n- Complexidade alta\n- Latência para reconstruir estado\n- Overhead de processamento\n\n**Por que foi descartada:** Complexidade excessiva para o caso de uso.\n","date":"2025-12-01T05:00:00Z","format":"Markdown","id":"4","status":"Accepted","title":"Read Model e Banco de Dados: MongoDB/Cassandra + Redis"},{"content":"# 5. API Management vs Spring Gateway\n\nDate: 2025-12-01\n\n## Status\n\nAccepted\n\n## Context\n\nA solução expõe APIs públicas que exigem autenticação, autorização, versionamento, quotas, monitoramento e possivelmente monetização. O Spring Cloud Gateway é usado internamente, mas não oferece funcionalidades de gestão de APIs.\n\n## Decision\n\nUtilizar um **API Management/Gateway dedicado** (Apigee, Kong ou Azure API Management) na borda. Essas plataformas fornecem gestão de ciclo de vida, portal de desenvolvedores, definição de planos de uso, throttling, analytics e suporte a padrões de segurança (OAuth2/OIDC) de forma centralizada.\n\n## Consequences\n\nO API Management dedicado adiciona custo e complexidade operacional, mas garante governança, versionamento e segurança de APIs, alinhado à estratégia corporativa de \"APIificação por domínio\".\n\n**Componentes Afetados:**\n- API Gateway\n\n## Alternatives Considered\n\n### 1. Spring Cloud Gateway\n**Descrição:** Gateway de aplicação leve integrado ao ecossistema Spring.\n\n**Prós:**\n- Leve e integrado ao Spring\n- Roteamento e filtros customizados\n- Baixo custo\n\n**Contras:**\n- Carece de funcionalidades de gestão de APIs\n- Sem portal de desenvolvedores\n- Monitoramento limitado\n\n**Por que foi descartada:** Não oferece governança e gestão de APIs corporativas.\n\n### 2. Nginx Ingress Controller\n**Descrição:** Controlador de ingress baseado em Nginx.\n\n**Prós:**\n- Performance alta\n- Maduro e estável\n- Baixo custo\n\n**Contras:**\n- API Gateway básico\n- Exige desenvolvimento adicional para políticas\n- Sem analytics avançado\n\n**Por que foi descartada:** Requer muito desenvolvimento customizado.\n","date":"2025-12-01T05:00:00Z","format":"Markdown","id":"5","status":"Accepted","title":"API Management vs Spring Gateway"},{"content":"# 6. Estratégia de Sincronização: Unidirecional\n\nDate: 2025-12-01\n\n## Status\n\nAccepted\n\n## Context\n\nOs sistemas de origem são o Salesforce e legados diversos. Alterar registros em mais de um sistema de origem simultaneamente aumenta a complexidade e risco de inconsistências.\n\n## Decision\n\nImplementar um fluxo **unidirecional** de atualização: as alterações em CRM ou legados são capturadas pelos conectores e publicadas no Event Bus. O Consolidador aplica regras de prioridade e atualiza o read model. Alterações no read model **não disparam** atualizações de volta aos sistemas de origem, exceto quando regras de negócio exigirem.\n\n## Consequences\n\nA sincronização unidirecional simplifica o fluxo e evita loops. A consistência entre sistemas de origem continua a cargo dos times desses sistemas. Alguns dados podem divergir temporariamente, mas a consulta sempre retornará o \"melhor dado\" conforme regras de prioridade.\n\n**Componentes Afetados:**\n- Conectores (CRM e Legados)\n- Consolidador de Dados\n\n## Alternatives Considered\n\n### 1. Sincronização Bi-direcional Automática\n**Descrição:** Toda alteração no read model seria propagada de volta aos sistemas de origem.\n\n**Prós:**\n- Maior consistência entre sistemas\n- Dados sempre sincronizados\n\n**Contras:**\n- Grande complexidade\n- Risco de loops de atualização\n- Resolução de conflitos transacionais\n\n**Por que foi descartada:** Complexidade excessiva e risco de loops.\n\n### 2. Consulta On-Demand aos Sistemas de Origem\n**Descrição:** API de consulta chamaria todos os sistemas em tempo real.\n\n**Prós:**\n- Dados sempre atualizados\n- Sem necessidade de consolidação\n\n**Contras:**\n- Impossibilita atingir SLA de milissegundos\n- Acoplamento forte\n- Dependência de disponibilidade de todos os sistemas\n\n**Por que foi descartada:** Não atende requisitos de performance e disponibilidade.\n","date":"2025-12-01T05:00:00Z","format":"Markdown","id":"6","status":"Accepted","title":"Estratégia de Sincronização: Unidirecional"},{"content":"# 7. Padrões de Resiliência\n\nDate: 2025-12-01\n\n## Status\n\nAccepted\n\n## Context\n\nOs legados podem estar indisponíveis ou instáveis, e falhas na mensageria ou na base de dados não podem impactar o SLA de consulta. É preciso garantir que o sistema degrade graciosamente.\n\n## Decision\n\nAdotar um conjunto de padrões de resiliência: **Circuit Breaker**, **Retry com backoff exponencial**, **Timeouts**, **Bulkheads**, **Dead Letter Queue (DLQ)** e **Idempotência** nos consumidores de eventos.\n\n## Consequences\n\nA aplicação desses padrões aumenta a complexidade de implementação, mas garante resiliência. Falhas nos legados não afetarão a API de consulta; o read model continuará a fornecer dados mais recentes disponíveis.\n\n**Componentes Afetados:**\n- Todos os microsserviços\n- Conectores\n- Consolidador\n\n## Alternatives Considered\n\n### 1. Abordagem Reativa Simples (Fail-Fast)\n**Descrição:** Falhar imediatamente sem retry ou circuit breaker.\n\n**Prós:**\n- Simplicidade de implementação\n- Menos overhead\n\n**Contras:**\n- Não trata falhas transitórias\n- Impacto direto na disponibilidade\n- Experiência do usuário degradada\n\n**Por que foi descartada:** Não atende requisitos de disponibilidade.\n\n### 2. Retry Agressivo Sem Circuit Breaker\n**Descrição:** Retry infinito sem proteção de circuit breaker.\n\n**Prós:**\n- Eventualmente recupera de falhas\n\n**Contras:**\n- Pode sobrecarregar sistemas já instáveis\n- Cascata de falhas\n- Timeout excessivo para o usuário\n\n**Por que foi descartada:** Risco de cascata de falhas e sobrecarga.\n","date":"2025-12-01T05:00:00Z","format":"Markdown","id":"7","status":"Accepted","title":"Padrões de Resiliência"},{"content":"# 8. Observabilidade Completa e OpenTelemetry\n\nDate: 2025-12-01\n\n## Status\n\nAccepted\n\n## Context\n\nA solução terá muitos microsserviços e integrações assíncronas. Precisamos rastrear requisições ponta a ponta e diagnosticar problemas rapidamente.\n\n## Decision\n\nAdotar **OpenTelemetry** como padrão de instrumentação. Todos os serviços geram **traces**, **métricas** e **logs** com context propagation. A coleta é feita pelo **OTel Collector**, com exportação para **Prometheus**, **Jaeger/Tempo** e **Elasticsearch/Grafana**.\n\n## Consequences\n\nA instrumentação via OTel exige configuração, mas padroniza a coleta e fornece flexibilidade para escolher backends. A correlação entre logs, métricas, traces e perfis facilita o troubleshooting.\n\n**Componentes Afetados:**\n- Observability Stack\n- Todos os microsserviços\n\n## Alternatives Considered\n\n### 1. Soluções Proprietárias (Datadog, New Relic)\n**Descrição:** Plataformas APM completas e gerenciadas.\n\n**Prós:**\n- APM completo out-of-the-box\n- Suporte e integrações prontas\n- Interface rica\n\n**Contras:**\n- Custo elevado\n- Vendor lock-in\n- Menos flexibilidade\n\n**Por que foi descartada:** Custo e dependência de fornecedor.\n\n### 2. Instrumentação Manual Sem Contexto Propagado\n**Descrição:** Logs e métricas sem correlação entre serviços.\n\n**Prós:**\n- Simplicidade inicial\n- Sem dependências externas\n\n**Contras:**\n- Não permite rastrear requisições entre microsserviços\n- Troubleshooting complexo\n- Sem visão end-to-end\n\n**Por que foi descartada:** Não atende requisitos de observabilidade distribuída.\n","date":"2025-12-01T05:00:00Z","format":"Markdown","id":"8","status":"Accepted","title":"Observabilidade Completa e OpenTelemetry"},{"content":"# 9. Estratégia de Deploy: Blue/Green e CI/CD\n\nDate: 2025-12-01\n\n## Status\n\nAccepted\n\n## Context\n\nPrecisamos implantar novas versões sem interrupção e reduzir risco. A área de CX da Vivo exige alta disponibilidade.\n\n## Decision\n\nAdotar **Blue/Green Deployment** nos ambientes de produção. Duas réplicas do ambiente coexistem; o tráfego é alternado via API Gateway. Os deployments são orquestrados por **Helm** e **Jenkins/Azure DevOps**.\n\n## Consequences\n\nBlue/Green adiciona custo mas oferece rollback rápido e controle de release. A estratégia pode evoluir para **Canary Releases** e **Feature Flags** para experimentação.\n\n**Componentes Afetados:**\n- Todos os containers em produção\n\n## Alternatives Considered\n\n### 1. Rolling Update\n**Descrição:** Atualização progressiva de pods.\n\n**Prós:**\n- Simples de implementar\n- Sem custo adicional de infraestrutura\n- Nativo do Kubernetes\n\n**Contras:**\n- Mistura versões diferentes durante deploy\n- Rollback mais lento\n- Dificuldade em validar nova versão isoladamente\n\n**Por que foi descartada:** Menor controle e rollback mais complexo.\n\n### 2. Canary Release\n**Descrição:** Libera apenas para parte do tráfego.\n\n**Prós:**\n- Adequado para experimentos A/B\n- Risco reduzido\n- Validação gradual\n\n**Contras:**\n- Mais complexo de implementar\n- Requer feature flags ou roteamento inteligente\n- Pode ser usado em conjunto com Blue/Green\n\n**Por que foi descartada:** Pode ser adotado posteriormente como evolução.\n","date":"2025-12-01T05:00:00Z","format":"Markdown","id":"9","status":"Accepted","title":"Estratégia de Deploy: Blue/Green e CI/CD"}],"sections":[{"content":"# Arquitetura de Solução - Plataforma de Consolidação de Dados de Cliente Vivo\n\n**Autor**: Gelson Perim **Data**: 01 de Dezembro de 2025\n\n## Sumário Executivo\n\nO cenário atual da Vivo/Telefônica, caracterizado pela fragmentação de dados de clientes em múltiplos sistemas de cadastro (CRM Salesforce e diversos legados), impõe um desafio significativo à agilidade e à qualidade da experiência do cliente. A ausência de um ponto único de consulta resulta em chamadas complexas e de alta latência, dificultando a obtenção de uma visão unificada e consistente do cliente em tempo real. Para endereçar este desafio, propomos a criação de uma **Plataforma de Consolidação de Dados de Cliente**, uma solução moderna e robusta projetada para fornecer uma visão de 360 graus do cliente com respostas em milissegundos.\n\nA arquitetura adota um conjunto de padrões de engenharia de software de ponta, incluindo **Domain-Driven Design (DDD)**, **Arquitetura Hexagonal**, **CQRS (Command Query Responsibility Segregation)** e uma abordagem **Event-Driven**. O núcleo da solução é a criação de um **Read Model otimizado (Customer Profile Store)**, alimentado de forma assíncrona por um **Event Bus (Apache Kafka)**. Este modelo é preenchido por um serviço de **Consolidação de Dados** que aplica regras de negócio para determinar o \"melhor dado\" a partir de eventos de alteração publicados pelos sistemas de origem.\n\nPara garantir a governança, segurança e resiliência, a plataforma é cercada por um **API Management dedicado**, um **Identity Provider** centralizado e um stack de **Observabilidade baseado em OpenTelemetry**. A evolução segura da arquitetura é garantida pelo uso de um **Schema Registry** para versionamento de eventos e **Feature Flags** para rollouts graduais. A resiliência é validada proativamente através de práticas de **Chaos Engineering**.\n\nEsta proposta detalha a visão narrativa da arquitetura, os fluxos de dados, as decisões arquiteturais (ADRs), e as estratégias para garantir desempenho, resiliência, escalabilidade, segurança, testes e a migração de dados. O resultado é uma plataforma desacoplada, resiliente e escalável, pronta para suportar as demandas atuais e futuras da Vivo, servindo como um pilar para a transformação digital da companhia.\n\n---\n\n## Visão Narrativa da Arquitetura\n\nO ecossistema da solução foi projetado para ser modular, desacoplado e altamente especializado, com cada componente desempenhando um papel claro na consolidação e exposição dos dados do cliente.\n\n### Componentes do Ecossistema\n\n| Componente | Tecnologia Sugerida | Descrição e Responsabilidades |\n| --- | --- | --- |\n| **CRM (Salesforce)** | Salesforce | Sistema de cadastro principal e fonte primária de dados de clientes. |\n| **Sistemas Legados** | Mainframe, Oracle DB, etc. | Aplicações antigas que ainda contêm dados relevantes de clientes e que precisam ser integrados. |\n| **API Management** | Apigee, Kong, Azure APIM | Camada de borda que expõe as APIs de forma segura, aplicando políticas de autenticação (OAuth 2.0), autorização, rate limiting, caching e coletando métricas de uso. |\n| **Identity Provider** | Keycloak, Azure AD B2C | Serviço centralizado responsável pela autenticação de usuários e aplicações, emitindo tokens JWT com os escopos e claims necessários. |\n| **Event Bus** | Apache Kafka | Espinha dorsal da arquitetura. Plataforma de streaming de eventos que garante a comunicação assíncrona e desacoplada entre os produtores (conectores) e consumidores (consolidador). |\n| **Schema Registry** | Confluent Schema Registry | Garante a governança e o versionamento dos schemas de eventos publicados no Kafka, prevenindo quebras de compatibilidade. |\n| **Conectores/Adaptadores** | Java + Spring Boot | Microsserviços responsáveis por se conectar aos sistemas de origem (CRM, legados), capturar alterações de dados (via CDC, webhooks, filas) e publicar eventos de domínio padronizados no Event Bus. |\n| **Consolidador de Dados** | Java + Spring Boot | Microsserviço que consome eventos do Event Bus, aplica regras de negócio complexas para reconciliar e priorizar dados de diferentes fontes, e atualiza o Read Model com o \"melhor dado\". |\n| **Customer Profile Store (Read Model)** | MongoDB / Cassandra + Redis | Repositório de dados altamente otimizado para leitura. Armazena o perfil consolidado do cliente em um formato desnormalizado para garantir consultas de baixa latência. Redis atua como cache distribuído (L1). |\n| **Customer Query Service (BFF)** | Java + Spring Boot | Backend-for-Frontend (BFF) que expõe a API REST/GraphQL de consulta. Contém um cache local (L2 com Caffeine) para performance extrema e orquestra a busca de dados no Customer Profile Store. |\n| **Observability Stack** | OpenTelemetry, Prometheus, Grafana, Jaeger | Conjunto de ferramentas para coleta, armazenamento e visualização de logs, métricas e traces distribuídos, fornecendo uma visão completa da saúde e performance do sistema. |\n| **Feature Flag Service** | LaunchDarkly, Unleash | Plataforma para gerenciar feature flags, permitindo o rollout gradual e controlado de novas funcionalidades e regras de negócio sem a necessidade de deploy. |\n| **Secrets Manager** | HashiCorp Vault, Azure Key Vault | Cofre centralizado para o gerenciamento seguro de segredos, como chaves de criptografia, senhas de banco de dados e tokens de API. |\n| **Chaos Engineering Tool** | Gremlin, LitmusChaos | Ferramenta para a injeção controlada de falhas em ambientes de produção, permitindo validar proativamente a resiliência da arquitetura. |\n\n### Fluxo de Consulta de Cliente (Leitura)\n\nO fluxo de consulta é otimizado para performance e baixa latência, seguindo os princípios do CQRS.\n\n1. **Requisição do Cliente**: Um usuário (seja um cliente no App Meu Vivo ou um atendente no CRM) inicia uma ação que requer dados do perfil do cliente. A aplicação cliente chama a API de consulta exposta no API Management.\n\n1. **Validação no API Gateway**: O API Gateway intercepta a requisição, valida o token JWT junto ao Identity Provider, verifica as permissões (escopos) e aplica políticas de rate limiting.\n\n1. **Chamada ao BFF**: A requisição é encaminhada para o **Customer Query Service (BFF)**.\n\n1. **Consulta ao Cache L2**: O BFF primeiro verifica seu cache local em memória (**L2 Cache com Caffeine**). Se o perfil solicitado estiver presente (cache hit), ele é retornado imediatamente, com latência na casa de um dígito de milissegundo.\n\n1. **Consulta ao Cache L1**: Se ocorrer um cache miss no L2, o BFF consulta o cache distribuído (**L1 Cache com Redis**). Se houver um hit, o dado é retornado e também armazenado no L2 para futuras requisições.\n\n1. **Consulta ao Read Model**: Se ocorrer um cache miss em ambos os níveis, o BFF finalmente consulta o **Customer Profile Store (MongoDB/Cassandra)**, que armazena o perfil consolidado. A resposta é então armazenada em ambos os caches (L1 e L2) antes de ser retornada ao cliente.\n\n1. **Resposta Rápida**: Graças a essa estratégia de caching multinível e ao modelo de dados otimizado, a resposta da API é entregue em dezenas de milissegundos, atendendo ao requisito de negócio.\n\n### Fluxo de Atualização de Dados (Escrita)\n\nO fluxo de atualização é assíncrono, desacoplado e resiliente, garantindo que o Read Model seja eventualmente consistente com os sistemas de origem.\n\n1. **Alteração na Origem**: Um dado de cliente é criado ou alterado em um dos sistemas de origem (ex: um atendente atualiza um endereço no CRM Salesforce).\n\n1. **Captura pelo Conector**: O **Conector** correspondente àquele sistema de origem captura a alteração. Isso pode ser feito através de mecanismos como Change Data Capture (CDC), webhooks, ou escuta de filas.\n\n1. **Publicação do Evento de Domínio**: O Conector transforma o evento bruto do sistema de origem em um evento de domínio padronizado (ex: `CustomerAddressUpdatedEvent`), valida seu schema contra o **Schema Registry**, e o publica em um tópico específico no **Event Bus (Kafka)**. (Ver **Apêndice A** para exemplos de schemas baseados no padrão TM Forum).\n\n1. **Consumo pelo Consolidador**: O **Consolidador de Dados**, que está inscrito no tópico, consome o evento. A idempotência é garantida através do rastreamento de IDs de eventos já processados.\n\n1. **Aplicação de Regras de Negócio**: O Consolidador consulta o **Feature Flag Service** para verificar se há regras de negócio experimentais ativas. Em seguida, ele aplica a lógica de priorização e reconciliação para determinar se o dado do evento deve sobrescrever o dado existente no perfil consolidado (ex: a alteração do CRM tem prioridade sobre uma alteração de um sistema legado).\n\n1. **Atualização do Read Model**: O Consolidador atualiza o registro correspondente no **Customer Profile Store (MongoDB/Cassandra)**.\n\n1. **Invalidação de Cache**: Após a atualização, o Consolidador publica um evento de invalidação em um tópico específico do Kafka (ex: `ProfileInvalidatedEvent`), que é consumido pelo BFF para remover o perfil obsoleto de seus caches (L1 e L2).\n\n1. **Publicação de Evento de Perfil Atualizado (Opcional)**: O Consolidador pode publicar um evento final (`CustomerProfileUpdatedEvent`) para notificar outros domínios de negócio (como Billing ou Marketing) sobre a atualização do perfil consolidado.\n\n---\n\n## Garantias de Desempenho, Resiliência e Escalabilidade\n\nA arquitetura foi projetada para atender a requisitos rigorosos de performance, disponibilidade e capacidade de crescimento.\n\n### Desempenho\n\nO desempenho é garantido através de múltiplas estratégias complementares que otimizam cada etapa do fluxo de consulta.\n\n**Read Model Especializado**: O Customer Profile Store é um banco de dados otimizado exclusivamente para leitura. Os dados são armazenados em um formato desnormalizado, eliminando a necessidade de joins complexos. Índices são criados em campos frequentemente consultados (CPF, telefone, email), garantindo que consultas retornem em poucos milissegundos.\n\n**Caching Multinível**: A estratégia de caching é dividida em três níveis. O **L1 Cache (Redis)** é um cache distribuído que armazena perfis acessados recentemente, com TTL configurável. O **L2 Cache (Caffeine)** é um cache local em memória em cada instância do BFF, armazenando os perfis mais acessados (\"quentes\") e oferecendo latências sub-milissegundo. Finalmente, o **HTTP Caching** no API Gateway pode cachear respostas para requisições idênticas por um curto período.\n\n**Escritas Assíncronas**: O fluxo de atualização é completamente assíncrono. Alterações nos sistemas de origem não bloqueiam a API de consulta. O desacoplamento via eventos garante que o read model seja atualizado de forma independente, sem impactar a latência de leitura.\n\n**CQRS**: A separação de responsabilidades entre leitura (Customer Query Service) e escrita (Consolidador) permite que cada caminho seja otimizado de forma independente. Comandos de cadastro atualizam o Read Model a partir dos sistemas de origem; consultas acessam o read model. Essa separação permite escalar leitura independentemente de escrita.\n\n**SLAs Definidos**: Estabelecemos os seguintes Service Level Indicators (SLIs) e Service Level Objectives (SLOs):\n\n| Métrica | SLO | Medição |\n| --- | --- | --- |\n| Latência p95 da API de consulta | < 99ms | Prometheus + Grafana |\n| Latência p99 da API de consulta | < 500ms | Prometheus + Grafana |\n| Disponibilidade da API | > 99.95% | Uptime monitoring |\n| Taxa de erro (5xx) | < 0.1% | Prometheus + Grafana |\n| Throughput | > 10.000 req/s | Load testing + Prometheus |\n\n### Resiliência\n\nA resiliência é obtida através da aplicação de padrões bem estabelecidos e da redundância em múltiplas camadas.\n\n**Circuit Breaker**: Cada adaptador de integração possui um circuit breaker que monitora a taxa de falhas. Se um sistema legado estiver indisponível, o breaker entra em estado `open` após um número configurável de falhas consecutivas, impedindo novas chamadas e retornando erro rápido ao cliente. Após um período de timeout, o breaker entra em estado `half-open` para testar se o sistema se recuperou.\n\n**Retry com Backoff Exponencial**: Chamadas externas (HTTP, SOAP) implementam retry automático com backoff exponencial. Por exemplo, a primeira tentativa ocorre imediatamente, a segunda após 1 segundo, a terceira após 2 segundos, e assim por diante. Isso evita sobrecarregar sistemas que estão se recuperando.\n\n**Timeouts**: Todos os clientes HTTP/SOAP e produtores/consumidores Kafka possuem timeouts configurados. Isso garante que uma chamada lenta não bloqueie indefinidamente um thread ou conexão.\n\n**Bulkheads**: Recursos são isolados por sistema de origem. Por exemplo, pools de conexões para o CRM são separados de pools para legados. Isso evita que um legado lento degrade os demais.\n\n**Dead Letter Queue (DLQ)**: Mensagens que falharem após várias tentativas são movidas para uma DLQ. Isso permite análise posterior e reprocessamento manual, sem bloquear o processamento de eventos válidos.\n\n**Idempotência**: Consumidores de eventos rastreiam IDs de eventos já processados (usando um campo `eventId` único). Se um evento for reprocessado (por exemplo, após um retry), o consumidor detecta a duplicação e ignora o evento, evitando efeitos colaterais.\n\n**Replicação e Redundância**: O Customer Profile Store (MongoDB/Cassandra) é configurado com replicação (mínimo de 3 réplicas). O Event Bus (Kafka) possui múltiplos brokers e replicação de partições. O Redis é configurado em modo cluster com replicação.\n\n### Escalabilidade\n\nA escalabilidade é suportada pela orquestração em Kubernetes/OpenShift e pelo uso de tecnologias que escalam horizontalmente.\n\n**Horizontal Pod Autoscaler (HPA)**: Cada microsserviço (Conectores, Consolidador, Query Service) é deployado em contêineres Docker com HPA monitorando CPU/memória e métricas customizadas. O HPA ajusta a quantidade de réplicas conforme a carga; o controlador do HPA consulta o Metrics Server periodicamente e recalcula o número de réplicas desejado.\n\n**Event Streaming com Partições**: O Kafka escala horizontalmente adicionando brokers, e o read model utiliza sharding e replicação para suportar picos. Tópicos do Kafka são particionados por hash do **Customer ID** (identificador único do cliente conforme TMF629), permitindo que múltiplos consumidores processem eventos em paralelo.\n\n**Sharding do Read Model**: O Customer Profile Store é particionado (sharded) pelo **Customer ID** (campo `id` do modelo TMF629 Customer). Este identificador é um UUID global e imutável que garante distribuição uniforme entre shards. Cada shard é replicado para garantir disponibilidade. Consultas que incluem o Customer ID são roteadas diretamente para o shard correspondente. Consultas por atributos secundários (CPF, telefone, email) utilizam índices secundários globais ou scatter-gather quando necessário.\n\n**Cache Distribuído**: O Redis é configurado em modo cluster, permitindo adicionar nós conforme necessário. O cache L2 (Caffeine) escala automaticamente com o número de instâncias do BFF.\n\n**Estratégias para Picos**: Para suportar picos de requisição (promoções, Black Friday, campanhas de marketing), a arquitetura utiliza:\n\n- **Auto-scaling horizontal**: HPA ajusta réplicas automaticamente.\n\n- **Event streaming**: Kafka absorve picos de escrita; consumidores podem aumentar suas réplicas para processar backlog.\n\n- **Caching agressivo**: Redis e Caffeine reduzem carga no banco.\n\n- **Throttling no API Gateway**: Políticas de rate limiting controlam quantas requisições cada consumidor pode fazer, evitando sobrecarga.\n\n- **Bulk head em Conectores**: Conexões com legados são isoladas em pools independentes, evitando que um legado lento degrade os demais. Circuit breaker previne saturação.\n\n---\n\n## Estratégia de Migração de Dados\n\nA migração de dados existentes dos sistemas de origem para o Customer Profile Store é uma etapa crítica que requer planejamento cuidadoso para evitar indisponibilidade e inconsistências.\n\n### 5.1. Abordagem de Migração\n\nA estratégia recomendada é uma **migração gradual com dual-write**, dividida em fases:\n\n**Fase 1 - Desenvolvimento dos Conectores**: Desenvolver e testar os conectores para CRM e legados em ambiente de desenvolvimento. Validar que os eventos de domínio estão sendo publicados corretamente no Kafka.\n\n**Fase 2 - Carga Inicial (Batch)**: Executar uma carga inicial em batch dos dados existentes durante uma janela de baixa utilização (ex: madrugada de fim de semana). Essa carga lê todos os registros dos sistemas de origem e popula o Customer Profile Store. O Consolidador aplica as regras de priorização para determinar o \"melhor dado\" para cada cliente. Essa fase pode levar várias horas ou dias, dependendo do volume de dados.\n\n**Fase 3 - Ativação dos Conectores (Dual-Write)**: Após a carga inicial, ativar os conectores em produção. A partir desse momento, todas as alterações nos sistemas de origem são capturadas e publicadas no Kafka. O Consolidador processa esses eventos em tempo real, mantendo o Customer Profile Store sincronizado.\n\n**Fase 4 - Validação e Reconciliação**: Executar um processo de reconciliação para comparar os dados no Customer Profile Store com os dados nos sistemas de origem. Identificar e corrigir discrepâncias. Essa fase pode ser executada de forma contínua por um período (ex: 1 semana).\n\n**Fase 5 - Cutover**: Após validar que o Customer Profile Store está consistente e atualizado, fazer o cutover: redirecionar o tráfego da API de consulta para o novo sistema. Monitorar métricas e logs de perto nas primeiras horas/dias.\n\n### 5.2. Considerações Técnicas\n\n**Volume de Dados**: Estimar o volume total de clientes (ex: 100 milhões) e o tamanho médio de cada perfil (ex: 10 KB). Isso determina a capacidade necessária do Customer Profile Store e o tempo de carga inicial.\n\n**Janela de Migração**: Identificar janelas de baixa utilização para executar a carga inicial. Considerar fazer a migração em múltiplas ondas (ex: migrar 10% dos clientes por vez) para reduzir o risco.\n\n**Validação de Dados**: Implementar scripts de validação que comparam os dados migrados com os dados de origem. Validar campos críticos (CPF, nome, telefone, endereço) e gerar relatórios de discrepâncias.\n\n**Rollback**: Manter os sistemas de origem ativos e funcionais durante todo o processo de migração. Em caso de problemas, o rollback consiste em redirecionar o tráfego de volta para os sistemas antigos.\n\n**Comunicação**: Comunicar claramente aos stakeholders (atendentes, clientes, áreas de negócio) sobre o cronograma de migração e possíveis impactos (ex: dados podem estar temporariamente desatualizados).\n\n---\n\n## Estratégia de Testes\n\nA qualidade da solução é garantida através de uma estratégia de testes abrangente que cobre múltiplos níveis.\n\n### 6.1. Testes Unitários\n\nCada componente (controllers, services, repositories) possui testes unitários escritos em **JUnit 5**. Mocks são criados usando **Mockito** para isolar dependências. A cobertura de código alvo é de **80%** para lógica de negócio crítica.\n\n### 6.2. Testes de Integração\n\nTestes de integração validam a interação entre componentes. Por exemplo, testar que o BFF consegue consultar o Customer Profile Store corretamente. Esses testes usam **TestContainers** para subir instâncias reais de MongoDB, Redis e Kafka em contêineres Docker durante a execução dos testes.\n\n### 6.3. Testes de Contrato\n\nPara garantir que produtores e consumidores de eventos estão alinhados, utilizamos **Pact** ou **Spring Cloud Contract** para testes de contrato. Produtores publicam contratos (schemas de eventos esperados), e consumidores validam que conseguem processar esses eventos.\n\n### 6.4. Testes End-to-End (E2E)\n\nUma suíte de testes E2E automatizados valida o fluxo completo da arquitetura:\n\n1. **Setup**: Subir um ambiente de testes com todos os componentes (API Gateway, BFF, Consolidador, Kafka, MongoDB, Redis).\n\n1. **Inserção de Dados**: Inserir um dado de teste em uma versão de teste do CRM (ou usar um mock).\n\n1. **Validação de Evento**: Verificar que o evento correspondente foi publicado no Kafka.\n\n1. **Processamento**: Aguardar o Consolidador processar o evento e atualizar o Customer Profile Store.\n\n1. **Consulta**: Consultar a API de consulta e validar que o dado está disponível e correto.\n\n1. **Teardown**: Limpar os dados de teste.\n\nEsses testes rodam no pipeline de CI/CD antes de cada deploy em produção.\n\n### 6.5. Testes de Carga e Performance\n\nTestes de carga são executados usando **Gatling** ou **JMeter** para simular milhares de requisições simultâneas. Objetivos:\n\n- Validar que a API de consulta atende ao SLO de latência (p95 < 150ms) sob carga.\n\n- Identificar gargalos (ex: pool de conexões insuficiente, cache mal dimensionado).\n\n- Validar que o HPA escala corretamente conforme a carga aumenta.\n\n### 6.6. Testes de Resiliência (Chaos Engineering)\n\nConforme descrito no ADR 13, testes de resiliência são executados usando **Gremlin** ou **LitmusChaos**. Exemplos de experimentos:\n\n- Derrubar pods aleatoriamente e verificar que o sistema se recupera automaticamente.\n\n- Introduzir latência em chamadas a legados e verificar que o circuit breaker funciona.\n\n- Simular indisponibilidade do Kafka e verificar que eventos são retidos e reprocessados após a recuperação.\n\n### 6.7. Testes de Segurança\n\nTestes de segurança incluem:\n\n- **Análise estática de código (SAST)**: Usar ferramentas como **SonarQube** ou **Checkmarx** para identificar vulnerabilidades no código.\n\n- **Análise de dependências**: Usar **OWASP Dependency-Check** para identificar bibliotecas com vulnerabilidades conhecidas.\n\n- **Testes de penetração (DAST)**: Contratar uma empresa especializada para executar testes de penetração na API de consulta, tentando explorar vulnerabilidades como SQL injection, XSS, CSRF, etc.\n\n- **Auditoria de acesso**: Validar que logs de auditoria registram corretamente quem acessou quais dados e quando.\n\n---\n\n## Segurança e Conformidade\n\nA segurança é tratada com a devida importância, com múltiplas camadas de proteção e conformidade com regulamentações como a LGPD.\n\n### 7.1. Autenticação e Autorização\n\n**Identity Provider Centralizado**: Todas as requisições à API de consulta passam por autenticação no Identity Provider (Keycloak ou Azure AD B2C). Usuários e aplicações recebem tokens JWT com escopos e claims que definem suas permissões.\n\n**OAuth 2.0 / OpenID Connect**: O API Gateway valida tokens JWT e propaga as identidades para os serviços internos. Para integrações entre serviços, usa-se **mTLS** (mutual TLS) para garantir que apenas serviços autorizados possam se comunicar.\n\n**Autorização Granular**: O BFF verifica os escopos e claims do token para determinar quais dados o usuário pode acessar. Por exemplo, um atendente pode ter acesso a dados de todos os clientes, enquanto um cliente no App Meu Vivo só pode acessar seus próprios dados.\n\n### 7.2. Criptografia\n\n**Dados em Trânsito**: Todas as comunicações externas (cliente → API Gateway) e internas (serviço → serviço) usam **TLS 1.3**. Certificados são gerenciados pelo Kubernetes (cert-manager) ou pelo API Management.\n\n**Dados em Repouso**: Dados sensíveis no Customer Profile Store (CPF, telefone, endereço, dados financeiros) são criptografados usando **AES-256**. Chaves de criptografia são gerenciadas pelo **Secrets Manager** (HashiCorp Vault ou Azure Key Vault) e rotacionadas automaticamente a cada 90 dias.\n\n### 7.3. Mascaramento e Anonimização\n\n**Logs e Traces**: Dados sensíveis são automaticamente mascarados em logs e traces. Por exemplo, um CPF \"123.456.789-00\" é registrado como \"***.***.***-00\". Isso é implementado usando filtros no OpenTelemetry Collector e no framework de logging (Logback).\n\n**Dashboards**: Dashboards do Grafana que exibem dados de clientes (para troubleshooting) aplicam mascaramento. Apenas usuários com permissões especiais podem visualizar dados completos.\n\n### 7.4. Auditoria e Trilhas de Acesso\n\n**Logs de Auditoria**: Todas as consultas à API de consulta geram logs de auditoria que registram:\n\n- Quem acessou (ID do usuário ou aplicação)\n\n- Qual cliente foi consultado (ID do cliente)\n\n- Quando (timestamp)\n\n- De onde (IP de origem)\n\n- Resultado (sucesso ou falha)\n\nEsses logs são armazenados em um sistema separado (Elasticsearch) com retenção de 7 anos, conforme exigido pela LGPD.\n\n**Alertas de Acesso Suspeito**: Alertas são configurados no Prometheus Alertmanager para detectar padrões suspeitos, como:\n\n- Um usuário acessando um número anormalmente alto de perfis em curto período.\n\n- Acessos fora do horário comercial.\n\n- Tentativas de acesso a perfis de clientes VIP por usuários não autorizados.\n\n### 7.5. Conformidade com LGPD\n\n**Direito de Acesso**: Clientes podem solicitar uma cópia de todos os dados que a Vivo possui sobre eles. A API de consulta suporta essa funcionalidade através de um endpoint específico.\n\n**Direito de Retificação**: Clientes podem solicitar correção de dados incorretos. Essa solicitação é processada através de um fluxo específico que atualiza o sistema de origem (CRM) e propaga a alteração via eventos.\n\n**Direito de Exclusão**: Clientes podem solicitar a exclusão de seus dados (direito ao esquecimento). Essa solicitação aciona um processo que:\n\n1. Marca o perfil como \"excluído\" no Customer Profile Store.\n\n1. Publica um evento de exclusão no Kafka.\n\n1. Sistemas de origem processam o evento e excluem ou anonimizam os dados.\n\n**Minimização de Dados**: Apenas os dados estritamente necessários são coletados e armazenados. Dados obsoletos são automaticamente excluídos após um período de retenção definido (ex: 5 anos após a última interação).\n\n**Consentimento**: O sistema rastreia o consentimento do cliente para diferentes finalidades (ex: marketing, compartilhamento com parceiros). Esses consentimentos são armazenados no perfil e respeitados em todas as operações.\n\n---\n\n## Observabilidade e Operação\n\nA observabilidade é um pilar fundamental da arquitetura, permitindo que a equipe de operações monitore, diagnostique e resolva problemas rapidamente.\n\n### 8.1. Logs Estruturados\n\nTodos os serviços geram logs estruturados em formato JSON, contendo no mínimo os seguintes campos:\n\n- `timestamp`: Data e hora do evento\n\n- `serviceName`: Nome do serviço que gerou o log\n\n- `correlationId`: ID único da requisição do usuário\n\n- `traceId`: ID do trace distribuído (OpenTelemetry)\n\n- `spanId`: ID do span atual\n\n- `level`: Nível do log (INFO, WARN, ERROR)\n\n- `message`: Mensagem descritiva\n\n- `context`: Dados contextuais adicionais (ex: ID do cliente, operação executada)\n\nOs logs são centralizados em um cluster **Elasticsearch/OpenSearch** com retenção configurável (ex: 30 dias para logs de aplicação, 7 anos para logs de auditoria). Dados pessoais são anonimizados automaticamente.\n\n### 8.2. Métricas de Negócio e Técnicas\n\nAs métricas são coletadas pelo **Prometheus** e visualizadas em dashboards do **Grafana**.\n\n**Métricas de Negócio**:\n\n- Tempo médio de resposta do serviço de consulta (histograma)\n\n- Taxa de consultas por segundo (por canal: CRM, App)\n\n- Número de perfis atualizados por minuto (consumidos pelo consolidador)\n\n- Taxa de erros (código 4xx/5xx) e percentil p95/p99 de latência\n\n- Tamanho do backlog de eventos no Kafka (por partição)\n\n**Métricas Técnicas**:\n\n- Utilização de CPU e memória de cada pod\n\n- Número de conexões ativas a banco de dados\n\n- Tempo de garbage collection (GC)\n\n- Número de threads ativas\n\n- Uso de pool de conexões\n\n- Offset lag de consumidores Kafka (diferença entre o último evento publicado e o último evento processado)\n\n- Tamanho de cache Redis (número de chaves, memória utilizada)\n\n- Taxa de hit/miss de cache (L1 e L2)\n\nO HPA utiliza métricas de CPU/memória para ajustar réplicas. Métricas customizadas (ex: taxa de consultas) podem ser usadas para auto-scaling mais inteligente.\n\n### 8.3. Tracing Distribuído e Profiling\n\nO **OpenTelemetry** propaga contexto (`traceparent`) em todas as chamadas. Cada requisição cria um **trace** composto de **spans** representando etapas:\n\n1. Span raiz: Requisição chega ao API Gateway\n\n1. Span filho: Gateway chama o BFF\n\n1. Span neto: BFF consulta o cache L2\n\n1. Span neto: BFF consulta o cache L1 (Redis)\n\n1. Span neto: BFF consulta o Customer Profile Store\n\nO OTel permite correlacionar logs com traces. As SDKs do OTel injetam automaticamente `traceId` e `spanId` nos logs. A coleta é feita pelo **OTel Collector**, com exportação para **Jaeger/Tempo** (traces) e **Elasticsearch/Grafana** (logs e dashboards).\n\nO **profiling de código** em tempo real, recém-suportado pelo OpenTelemetry, permite identificar gargalos até o nível de função. Perfis de CPU e memória ligados a métricas e traces possibilitam análise de código-fonte em requisições lentas. Ferramentas como **Grafana Pyroscope** ou **FlameGraphs** podem ser integradas para visualização.\n\n### 8.4. Dashboards e Alertas\n\nPainéis em **Grafana** apresentam:\n\n1. **Painel de SLA de Consulta**: Latência média, percentis (p50, p95, p99), taxa de chamadas e taxa de erro. Indica se o SLA de milissegundos está sendo cumprido.\n\n1. **Painel de Fluxo de Atualização**: Número de eventos recebidos do CRM e legados, backlog de Kafka, tempo de processamento no consolidador e número de falhas (DLQ).\n\n1. **Painel de Infraestrutura**: CPU/memória dos pods, utilização de disco no read model, lag de consumidores e disponibilidade dos brokers Kafka.\n\n1. **Painel de Segurança**: Requisições autenticadas, tokens expirados/inválidos e tentativas de acesso indevido.\n\nAlertas principais são configurados no **Prometheus Alertmanager** e/ou **Azure Monitor** para eventos como:\n\n- Latência acima de p95 definido (> 99ms)\n\n- Backlog de eventos superior a limiar (ex: > 10.000 eventos)\n\n- Pod sem réplicas suficientes (< 2 réplicas ativas)\n\n- Falhas consecutivas em conectores legados (> 5 falhas em 5 minutos)\n\n- Circuit breaker em estado `open` por tempo prolongado (> 5 minutos)\n\n- Taxa de erros (4xx/5xx) anormal (> 1%)\n\n---\n\n## Escalabilidade e Estratégias para Picos\n\nPara suportar picos de requisição (promoções, Black Friday, campanhas de marketing), a arquitetura utiliza as seguintes estratégias combinadas.\n\n### 9.1. Auto-Scaling Horizontal\n\nCada microsserviço é configurado com **Horizontal Pod Autoscaler (HPA)**, que ajusta o número de réplicas com base em métricas de CPU ou métricas customizadas (como taxa de requisições ou lag de Kafka). O controlador do HPA consulta o Metrics Server periodicamente e recalcula o número de réplicas desejado.\n\n### 9.2. Event Streaming\n\nO Kafka absorve picos de escrita; consumidores podem aumentar suas réplicas para processar backlog. O event bus mantém eventos persistidos até serem consumidos, evitando perda de dados.\n\n### 9.3. Caching Agressivo\n\nO uso de Redis (L1) e Caffeine (L2) reduz drasticamente a carga no banco de dados. Em cenários de pico, o cache servirá a maioria das requisições, reduzindo a carga no Customer Profile Store.\n\n### 9.4. Throttling no API Gateway\n\nPolíticas de rate limiting controlam quantas requisições cada consumidor pode fazer, evitando sobrecarga. Por exemplo, um cliente pode fazer no máximo 100 requisições por minuto.\n\n### 9.5. Bulk Head em Conectores\n\nConexões com legados são isoladas em pools independentes, evitando que um legado lento degrade os demais. Circuit breaker previne saturação.\n\n### 9.6. Pré-Aquecimento de Cache\n\nAntes de eventos conhecidos (ex: Black Friday), executar um processo de pré-aquecimento de cache que carrega os perfis mais acessados no Redis e Caffeine, garantindo que eles estejam disponíveis imediatamente.\n\n---\n\n## Conclusão\n\nA Plataforma de Consolidação de Dados de Cliente proposta representa uma solução moderna, robusta e escalável para o desafio de unificar dados fragmentados em múltiplos sistemas. A arquitetura adota padrões de engenharia de software de ponta (DDD, Hexagonal, CQRS, Event-Driven), tecnologias consolidadas (Kafka, Kubernetes, OpenTelemetry) e práticas operacionais avançadas (Chaos Engineering, Feature Flags, Schema Registry).\n\nOs benefícios esperados incluem:\n\n- **Redução de latência**: Consultas em milissegundos através de read model otimizado e caching multinível.\n\n- **Desacoplamento**: Sistemas de origem não se conhecem; comunicação via eventos.\n\n- **Escalabilidade**: Capacidade de suportar milhões de clientes e picos de demanda.\n\n- **Resiliência**: Múltiplas camadas de proteção (Circuit Breaker, Retry, DLQ, Idempotência).\n\n- **Observabilidade**: Visão completa da saúde e performance através de logs, métricas e traces.\n\n- **Segurança**: Conformidade com LGPD e proteção de dados sensíveis.\n\n- **Evolução segura**: Schema Registry, Feature Flags e Chaos Engineering garantem evolução sem quebras.\n\nEsta plataforma não apenas resolve o problema imediato de consolidação de dados, mas também cria um ativo estratégico para a Vivo, servindo como um blueprint para futuras iniciativas de modernização e transformação digital. A arquitetura está pronta para ser implementada e evoluir de forma incremental, garantindo entrega de valor contínua ao negócio.\n\n\n\n---\n\n## Apêndice A - Schemas de Eventos (Padrão TM Forum)\n\nA governança de eventos é garantida pelo uso de um **Schema Registry** e pela padronização dos schemas com base nas OpenAPIs do **TM Forum**. Abaixo estão exemplos de schemas em formato **Avro** para os principais eventos de domínio.\n\n### A.1. Schema para `CustomerUpdatedEvent` (Baseado em TMF629)\n\nEste evento é publicado sempre que um dado de cliente é alterado em um sistema de origem. Ele contém o payload completo do cliente atualizado.\n\n```json\n{\n  \"type\": \"record\",\n  \"name\": \"CustomerUpdatedEvent\",\n  \"namespace\": \"com.vivo.customer.events.v1\",\n  \"doc\": \"Evento publicado quando um perfil de cliente é atualizado em um sistema de origem.\",\n  \"fields\": [\n    {\n      \"name\": \"eventId\",\n      \"type\": \"string\",\n      \"doc\": \"ID único do evento (UUID).\"\n    },\n    {\n      \"name\": \"eventTime\",\n      \"type\": \"long\",\n      \"logicalType\": \"timestamp-millis\",\n      \"doc\": \"Timestamp da ocorrência do evento.\"\n    },\n    {\n      \"name\": \"sourceSystem\",\n      \"type\": \"string\",\n      \"doc\": \"Sistema de origem que gerou o evento (ex: Salesforce, LegadoXPTO).\"\n    },\n    {\n      \"name\": \"correlationId\",\n      \"type\": \"string\",\n      \"doc\": \"ID de correlação para rastreamento ponta a ponta.\"\n    },\n    {\n      \"name\": \"customer\",\n      \"type\": {\n        \"type\": \"record\",\n        \"name\": \"CustomerPayload\",\n        \"doc\": \"Payload do cliente, baseado na Open API TMF629.\",\n        \"fields\": [\n          {\n            \"name\": \"id\",\n            \"type\": \"string\",\n            \"doc\": \"ID único do cliente na Vivo.\"\n          },\n          {\n            \"name\": \"name\",\n            \"type\": \"string\",\n            \"doc\": \"Nome completo do cliente.\"\n          },\n          {\n            \"name\": \"status\",\n            \"type\": [\"null\", \"string\"],\n            \"default\": null,\n            \"doc\": \"Status do cliente (ex: active, suspended, closed).\"\n          },\n          {\n            \"name\": \"contactMedium\",\n            \"type\": {\n              \"type\": \"array\",\n              \"items\": {\n                \"type\": \"record\",\n                \"name\": \"ContactMedium\",\n                \"fields\": [\n                  {\n                    \"name\": \"mediumType\",\n                    \"type\": \"string\",\n                    \"doc\": \"Tipo de contato (ex: email, phone, postalAddress).\"\n                  },\n                  {\n                    \"name\": \"preferred\",\n                    \"type\": \"boolean\",\n                    \"default\": false\n                  },\n                  {\n                    \"name\": \"characteristic\",\n                    \"type\": {\n                      \"type\": \"record\",\n                      \"name\": \"MediumCharacteristic\",\n                      \"fields\": [\n                        {\n                          \"name\": \"emailAddress\",\n                          \"type\": [\"null\", \"string\"],\n                          \"default\": null\n                        },\n                        {\n                          \"name\": \"phoneNumber\",\n                          \"type\": [\"null\", \"string\"],\n                          \"default\": null\n                        },\n                        {\n                          \"name\": \"street1\",\n                          \"type\": [\"null\", \"string\"],\n                          \"default\": null\n                        },\n                        {\n                          \"name\": \"city\",\n                          \"type\": [\"null\", \"string\"],\n                          \"default\": null\n                        },\n                        {\n                          \"name\": \"postcode\",\n                          \"type\": [\"null\", \"string\"],\n                          \"default\": null\n                        }\n                      ]\n                    }\n                  }\n                ]\n              }\n            },\n            \"default\": []\n          }\n        ]\n      }\n    }\n  ]\n}\n```\n\n### A.2. Schema para `ProfileInvalidatedEvent`\n\nEste evento é publicado pelo Consolidador após atualizar o read model. Ele é consumido pelo BFF para invalidar os caches L1 (Redis) e L2 (Caffeine), garantindo que a próxima consulta busque o dado atualizado.\n\n```json\n{\n  \"type\": \"record\",\n  \"name\": \"ProfileInvalidatedEvent\",\n  \"namespace\": \"com.vivo.customer.events.v1\",\n  \"doc\": \"Evento publicado para notificar a invalidação de um perfil de cliente no cache.\",\n  \"fields\": [\n    {\n      \"name\": \"eventId\",\n      \"type\": \"string\",\n      \"doc\": \"ID único do evento (UUID).\"\n    },\n    {\n      \"name\": \"eventTime\",\n      \"type\": \"long\",\n      \"logicalType\": \"timestamp-millis\",\n      \"doc\": \"Timestamp da ocorrência do evento.\"\n    },\n    {\n      \"name\": \"customerId\",\n      \"type\": \"string\",\n      \"doc\": \"ID do cliente cujo perfil foi invalidado.\"\n    }\n  ]\n}\n```\n\n### A.3. Evolução de Schemas\n\nA evolução dos schemas é gerenciada pelo Schema Registry com a regra de compatibilidade **`BACKWARD`**. Isso significa que:\n\n- **Novos campos podem ser adicionados**, desde que tenham um valor padrão (`default`). Consumidores antigos simplesmente ignorarão o novo campo.\n- **Campos existentes não podem ser removidos**.\n\nEssa estratégia garante que a adição de novos atributos ao perfil do cliente não quebre os consumidores existentes, permitindo uma evolução segura e desacoplada da plataforma.\n\n\n---\n\n## Apêndice B - Rastreabilidade ADR → Componentes\n\nEsta tabela mapeia cada Decisão de Arquitetura (ADR) aos componentes do sistema que são diretamente afetados por ela, garantindo rastreabilidade entre as decisões e a implementação.\n\n| ADR | Título da Decisão | Componente(s) Afetado(s) | Justificativa |\n| :--- | :--- | :--- | :--- |\n| **ADR 1** | Arquitetura Hexagonal/DDD | Customer Query Service (BFF), Consolidador de Dados | Estrutura interna em camadas (domínio, aplicação, adaptadores) para isolar regras de negócio. |\n| **ADR 2** | Linguagem: Java + Spring Boot | Todos os microsserviços | Plataforma padrão para desenvolvimento, aproveitando ecossistema e expertise existente. |\n| **ADR 3** | Mensageria: Kafka | Event Bus, Conectores, Consolidador | Espinha dorsal para comunicação assíncrona, garantindo desacoplamento e escalabilidade. |\n| **ADR 4** | Read Model: NoSQL + Cache | Customer Profile Store, BFF, Consolidador | Otimização de leitura com MongoDB/Cassandra e caching multinível (Redis + Caffeine). |\n| **ADR 5** | API Management | API Gateway | Governança centralizada de APIs na borda (segurança, versionamento, throttling). |\n| **ADR 6** | Sincronização Unidirecional | Conectores, Consolidador | Simplifica o fluxo de dados, evitando loops de atualização e complexidade de sincronização bi-direcional. |\n| **ADR 7** | Padrões de Resiliência | Todos os microsserviços | Implementação de Circuit Breaker, Retry, Timeouts, etc., para garantir alta disponibilidade. |\n| **ADR 8** | Observabilidade com OTel | Observability Stack, Todos os microsserviços | Padrão de instrumentação para traces, métricas e logs, permitindo rastreabilidade ponta a ponta. |\n| **ADR 9** | Deploy: Blue/Green | Todos os containers em produção | Estratégia de deploy sem downtime, permitindo validação segura e rollback rápido. |\n| **ADR 10** | TM Forum OpenAPIs | API Gateway, BFF, Schema Registry | Alinhamento com padrões da indústria de telecom para modelagem de APIs e eventos. |\n| **ADR 11** | Schema Registry | Schema Registry, Conectores, Consolidador | Governança e versionamento de schemas de eventos para evitar quebras de compatibilidade. |\n| **ADR 12** | Feature Flags | Feature Flag Service, BFF, Consolidador | Controle de rollout gradual (Canary Releases) e A/B testing de funcionalidades em produção. |\n| **ADR 13** | Chaos Engineering | Chaos Engineering Tool, Todos os microsserviços | Validação proativa da resiliência da arquitetura através da injeção controlada de falhas. |\n| **ADR 14** | Secrets Manager | Secrets Manager, BFF, Consolidador | Gestão centralizada e segura de chaves de criptografia e credenciais sensíveis. |\n","filename":"01-arquitetura-completa.md","format":"Markdown","order":1,"title":""}]},"id":1,"lastModifiedAgent":"structurizr-ui","lastModifiedDate":"2025-12-02T01:19:40Z","lastModifiedUser":"structurizr","model":{"deploymentNodes":[{"children":[{"description":"Camada de segurança de perímetro com firewall, WAF e load balancer","environment":"Production","id":"59","infrastructureNodes":[{"description":"Firewall L4 para filtragem de pacotes","environment":"Production","id":"60","name":"Firewall de Rede","properties":{"structurizr.dsl.identifier":"firewall"},"relationships":[{"description":"Encaminha tráfego filtrado","destinationId":"61","id":"63","sourceId":"60","tags":"Relationship","technology":"TCP/IP"}],"tags":"Element,Infrastructure Node","technology":"Firewall/L4"},{"description":"Web Application Firewall para proteção contra ataques OWASP Top 10","environment":"Production","id":"61","name":"WAF","properties":{"structurizr.dsl.identifier":"waf"},"relationships":[{"description":"Encaminha tráfego validado","destinationId":"62","id":"64","sourceId":"61","tags":"Relationship","technology":"HTTPS"}],"tags":"Element,Infrastructure Node","technology":"Web Application Firewall"},{"description":"Load Balancer L7 para distribuição de tráfego HTTP/HTTPS","environment":"Production","id":"62","name":"Load Balancer Externo","properties":{"structurizr.dsl.identifier":"lb"},"relationships":[{"description":"Roteia tráfego para ambiente blue","destinationId":"66","id":"78","sourceId":"62","tags":"Relationship","technology":"HTTPS"},{"description":"Roteia tráfego para ambiente green","destinationId":"70","id":"79","sourceId":"62","tags":"Relationship","technology":"HTTPS"}],"tags":"Element,Infrastructure Node","technology":"L7 Load Balancer"}],"instances":"1","name":"Perímetro de Rede","properties":{"structurizr.dsl.identifier":"994b60fe-6050-48d3-acc9-62f004d7f58a"},"tags":"Element,Deployment Node","technology":"Network Security"},{"containerInstances":[{"containerId":"12","deploymentGroups":["Default"],"environment":"Production","id":"66","instanceId":1,"properties":{"structurizr.dsl.identifier":"apigwBlue"},"tags":"Container Instance,blue"},{"containerId":"13","deploymentGroups":["Default"],"environment":"Production","id":"67","instanceId":1,"properties":{"structurizr.dsl.identifier":"bdea458d-76b8-4ad1-9cf5-d8c144bb5187"},"tags":"Container Instance,blue"},{"containerId":"31","deploymentGroups":["Default"],"environment":"Production","id":"68","instanceId":1,"properties":{"structurizr.dsl.identifier":"ae123ad8-cbd7-4426-bc44-722f31e3c639"},"tags":"Container Instance,blue"}],"description":"Ambiente blue para deploy blue/green","environment":"Production","id":"65","instances":"1","name":"Blue Environment","properties":{"structurizr.dsl.identifier":"493210b8-61d7-4f8b-a7ba-5bb875d6df1f"},"tags":"Element,Deployment Node","technology":"Kubernetes Namespace"},{"containerInstances":[{"containerId":"12","deploymentGroups":["Default"],"environment":"Production","id":"70","instanceId":1,"properties":{"structurizr.dsl.identifier":"apigwGreen"},"tags":"Container Instance,green"},{"containerId":"13","deploymentGroups":["Default"],"environment":"Production","id":"71","instanceId":1,"properties":{"structurizr.dsl.identifier":"86202177-8731-491b-8fe0-03f3ee7d27de"},"tags":"Container Instance,green"},{"containerId":"31","deploymentGroups":["Default"],"environment":"Production","id":"72","instanceId":1,"properties":{"structurizr.dsl.identifier":"9dcf3c84-d242-41b0-86cb-c700fbc25a25"},"tags":"Container Instance,green"}],"description":"Ambiente green para deploy blue/green","environment":"Production","id":"69","instances":"1","name":"Green Environment","properties":{"structurizr.dsl.identifier":"49480341-643a-4e7d-b278-ee27c04a06c1"},"tags":"Element,Deployment Node","technology":"Kubernetes Namespace"},{"containerInstances":[{"containerId":"23","deploymentGroups":["Default"],"environment":"Production","id":"74","instanceId":1,"properties":{"structurizr.dsl.identifier":"206d7152-d89b-42e1-9612-7d8f77b66399"},"tags":"Container Instance"},{"containerId":"41","deploymentGroups":["Default"],"environment":"Production","id":"75","instanceId":1,"properties":{"structurizr.dsl.identifier":"f25d31aa-63a3-4c49-aac6-d46ff50b36ad"},"tags":"Container Instance"},{"containerId":"42","deploymentGroups":["Default"],"environment":"Production","id":"76","instanceId":1,"properties":{"structurizr.dsl.identifier":"f964211b-2ca1-4cb2-91dd-a1308d455481"},"tags":"Container Instance"},{"containerId":"56","deploymentGroups":["Default"],"environment":"Production","id":"77","instanceId":1,"properties":{"structurizr.dsl.identifier":"496db358-df54-49fe-a8f3-7b240a0fdec4"},"tags":"Container Instance"}],"description":"Serviços compartilhados entre ambientes blue e green","environment":"Production","id":"73","instances":"1","name":"Shared Services","properties":{"structurizr.dsl.identifier":"72e39796-9c4f-4f4a-84ec-bb6a7990eb21"},"tags":"Element,Deployment Node","technology":"Kubernetes Namespace"}],"description":"Cluster Kubernetes gerenciado para execução dos containers","environment":"Production","id":"58","instances":"1","name":"Kubernetes/OpenShift Cluster","properties":{"structurizr.dsl.identifier":"57b1c822-62db-49b8-9e25-4d100e30a59c"},"tags":"Element,Deployment Node","technology":"Kubernetes 1.28+"}],"people":[{"description":"Operador que consulta dados do cliente no CRM.","id":"1","name":"Atendente CRM","properties":{"structurizr.dsl.identifier":"atendente"},"relationships":[{"description":"Consulta cliente via CRM","destinationId":"12","id":"80","sourceId":"1","tags":"Relationship","technology":"HTTPS"},{"description":"Consulta cliente via CRM","destinationId":"11","id":"81","linkedRelationshipId":"80","sourceId":"1","technology":"HTTPS"}],"tags":"Element,Person,Pessoa"},{"description":"Usuário final que consulta seus dados e histórico.","id":"2","name":"Cliente (App Meu Vivo)","properties":{"structurizr.dsl.identifier":"cliente"},"relationships":[{"description":"Consulta cliente via app","destinationId":"12","id":"82","sourceId":"2","tags":"Relationship","technology":"HTTPS"},{"description":"Consulta cliente via app","destinationId":"11","id":"83","linkedRelationshipId":"82","sourceId":"2","technology":"HTTPS"}],"tags":"Element,Person,Pessoa"},{"description":"Equipa de operações que monitora a solução.","id":"3","name":"Operador de suporte","properties":{"structurizr.dsl.identifier":"operador"},"tags":"Element,Person,Pessoa"}],"softwareSystems":[{"description":"Sistema de cadastro e atendimento (Salesforce).","documentation":{},"id":"4","name":"CRM Salesforce","properties":{"structurizr.dsl.identifier":"crm"},"tags":"Element,Software System,SistemaExterno"},{"description":"Diversos sistemas legados que mantêm dados de cliente.","documentation":{},"id":"5","name":"Sistemas Legados","properties":{"structurizr.dsl.identifier":"legados"},"tags":"Element,Software System,SistemaExterno"},{"description":"Serviço de autenticação/autorização (Keycloak/Azure AD).","documentation":{},"id":"6","name":"Identity Provider","properties":{"structurizr.dsl.identifier":"idp"},"relationships":[{"description":"Autentica tokens","destinationId":"12","id":"106","sourceId":"6","tags":"Relationship","technology":"OAuth2/OpenID Connect"},{"description":"Autentica tokens","destinationId":"11","id":"107","linkedRelationshipId":"106","sourceId":"6","technology":"OAuth2/OpenID Connect"}],"tags":"Element,Software System,SistemaExterno,Seguranca"},{"description":"Armazena e valida schemas de eventos do Kafka, garantindo compatibilidade entre produtores e consumidores.","documentation":{},"id":"7","name":"Schema Registry","properties":{"structurizr.dsl.identifier":"schemaRegistry"},"tags":"Element,Software System,Confluent Schema Registry / Apicurio,SistemaExterno,Infraestrutura"},{"description":"Gerencia feature flags para rollout gradual, A/B testing e desativação de funcionalidades.","documentation":{},"id":"8","name":"Feature Flag Service","properties":{"structurizr.dsl.identifier":"featureFlagService"},"tags":"Element,Software System,LaunchDarkly / Unleash,SistemaExterno,Infraestrutura"},{"description":"Plataforma para injetar falhas controladas e validar resiliência da arquitetura.","documentation":{},"id":"9","name":"Chaos Engineering Tool","properties":{"structurizr.dsl.identifier":"chaosEngineeringTool"},"relationships":[{"description":"Injeta falhas (latência, erros)","destinationId":"13","id":"111","sourceId":"9","tags":"Relationship","technology":"Chaos Experiments"},{"description":"Injeta falhas (latência, erros)","destinationId":"11","id":"112","linkedRelationshipId":"111","sourceId":"9","technology":"Chaos Experiments"},{"description":"Injeta falhas","destinationId":"31","id":"113","sourceId":"9","tags":"Relationship","technology":"Chaos Experiments"},{"description":"Simula indisponibilidade","destinationId":"41","id":"114","sourceId":"9","tags":"Relationship","technology":"Chaos Experiments"}],"tags":"Element,Software System,Gremlin / LitmusChaos,SistemaExterno,Infraestrutura"},{"description":"Cofre de segredos para gerenciar chaves de criptografia e credenciais sensíveis.","documentation":{},"id":"10","name":"Secrets Manager","properties":{"structurizr.dsl.identifier":"secretsManager"},"tags":"Element,Software System,HashiCorp Vault / Azure Key Vault,SistemaExterno,Seguranca"},{"containers":[{"description":"Camada de borda que expõe APIs, autentica requisições e aplica políticas de rate limiting.","documentation":{},"id":"12","name":"API Gateway","properties":{"structurizr.dsl.identifier":"apigw"},"relationships":[{"description":"Chama API de consulta","destinationId":"13","id":"84","sourceId":"12","tags":"Relationship","technology":"HTTP/REST + JWT"},{"description":"Delegates authentication/authorization","destinationId":"56","id":"110","sourceId":"12","tags":"Relationship","technology":"OAuth2"}],"tags":"Element,Container,Gateway","technology":"Nginx/Kong/Apigee"},{"components":[{"description":"Controlador REST que recebe requisições de consulta e retorna perfil.","documentation":{},"id":"14","name":"CustomerQueryController","properties":{"structurizr.dsl.identifier":"bffController"},"relationships":[{"description":"delegates","destinationId":"15","id":"19","sourceId":"14","tags":"Relationship","technology":"Method Call"}],"tags":"Element,Component,Componente,Controller","technology":"Spring Web"},{"description":"Camada de aplicação que orquestra a consulta ao read model e mapeia DTOs.","documentation":{},"id":"15","name":"CustomerQueryService (Application)","properties":{"structurizr.dsl.identifier":"bffService"},"relationships":[{"description":"verifica cache local primeiro","destinationId":"18","id":"20","sourceId":"15","tags":"Relationship","technology":"In-Memory API"},{"description":"consulta perfil se cache miss","destinationId":"17","id":"21","sourceId":"15","tags":"Relationship","technology":"Repository Pattern"},{"description":"monta perfil","destinationId":"16","id":"22","sourceId":"15","tags":"Relationship","technology":"Domain Model"}],"tags":"Element,Component,Componente,Service","technology":"Spring Service"},{"description":"Entidade de domínio representando o perfil de cliente.","documentation":{},"id":"16","name":"CustomerProfile","properties":{"structurizr.dsl.identifier":"bffDomain"},"tags":"Element,Component,Componente,Domain","technology":"DDD Aggregate"},{"description":"Porta de saída que acessa o read model (MongoDB/Cassandra) ou cache.","documentation":{},"id":"17","name":"ProfileRepository","properties":{"structurizr.dsl.identifier":"bffRepo"},"tags":"Element,Component,Componente,Repository","technology":"Port/Adapter"},{"description":"Cache local em memória (Caffeine) para perfis frequentemente acessados.","documentation":{},"id":"18","name":"L2 Cache","properties":{"structurizr.dsl.identifier":"bffL2Cache"},"tags":"Element,Component,Componente,Cache","technology":"Caffeine Cache"}],"description":"Microsserviço BFF que expõe a API de consulta de cliente, valida requisições e acessa o read model.","documentation":{},"id":"13","name":"Customer Query Service","properties":{"structurizr.dsl.identifier":"bff"},"relationships":[{"description":"Lê perfil","destinationId":"23","id":"85","sourceId":"13","tags":"Relationship","technology":"MongoDB/Cassandra Query"},{"description":"Verifica scopes/claims","destinationId":"56","id":"86","sourceId":"13","tags":"Relationship","technology":"JWT"},{"description":"Emite métricas e traces","destinationId":"42","id":"87","sourceId":"13","tags":"Relationship","technology":"OTel"},{"description":"Consulta feature flags","destinationId":"8","id":"88","sourceId":"13","tags":"Relationship","technology":"HTTP/REST"},{"description":"Obtém chaves de criptografia","destinationId":"10","id":"90","sourceId":"13","tags":"Relationship","technology":"HTTP/REST"}],"tags":"Element,Container,Aplicacao","technology":"Java + Spring Boot"},{"components":[{"description":"Banco de dados NoSQL distribuído para persistência do perfil consolidado.","documentation":{},"id":"24","name":"MongoDB/Cassandra Cluster","properties":{"structurizr.dsl.identifier":"mongoCluster"},"tags":"Element,Component,Componente,Banco","technology":"MongoDB/Cassandra"},{"description":"Cache distribuído em memória para perfis acessados recentemente.","documentation":{},"id":"25","name":"Redis Cluster (L1 Cache)","properties":{"structurizr.dsl.identifier":"redisCluster"},"relationships":[{"description":"cache miss, consulta banco","destinationId":"24","id":"30","sourceId":"25","tags":"Relationship","technology":"MongoDB Query"}],"tags":"Element,Component,Componente,Cache","technology":"Redis"},{"description":"Gerencia particionamento e roteamento de consultas entre shards.","documentation":{},"id":"26","name":"Shard Manager","properties":{"structurizr.dsl.identifier":"shardManager"},"relationships":[{"description":"roteia consultas para shard correto","destinationId":"24","id":"28","sourceId":"26","tags":"Relationship","technology":"MongoDB Protocol"}],"tags":"Element,Component,Componente,Infraestrutura","technology":"Sharding Logic"},{"description":"Gerencia replicação de dados entre nós para alta disponibilidade.","documentation":{},"id":"27","name":"Replication Manager","properties":{"structurizr.dsl.identifier":"replicationManager"},"relationships":[{"description":"replica dados entre nós","destinationId":"24","id":"29","sourceId":"27","tags":"Relationship","technology":"Replication Protocol"}],"tags":"Element,Component,Componente,Infraestrutura","technology":"Replication Logic"}],"description":"Banco de dados e cache contendo o melhor dado de cada cliente, otimizado para leitura.","documentation":{},"id":"23","name":"Customer Profile Store","properties":{"structurizr.dsl.identifier":"readmodel"},"tags":"Element,Container,Banco","technology":"MongoDB/Cassandra + Redis"},{"components":[{"description":"Componente que consome eventos de cliente do Event Bus.","documentation":{},"id":"32","name":"EventConsumer","properties":{"structurizr.dsl.identifier":"consConsumer"},"relationships":[{"description":"envia para","destinationId":"33","id":"36","sourceId":"32","tags":"Relationship","technology":"Event Processing"}],"tags":"Element,Component,Componente,Consumer","technology":"Kafka Listener"},{"description":"Aplica regras de reconciliação, priorização e idempotência.","documentation":{},"id":"33","name":"ProfileMergerService","properties":{"structurizr.dsl.identifier":"consService"},"relationships":[{"description":"atualiza read model","destinationId":"34","id":"37","sourceId":"33","tags":"Relationship","technology":"Repository Pattern"},{"description":"publica eventos","destinationId":"35","id":"38","sourceId":"33","tags":"Relationship","technology":"Kafka Producer API"}],"tags":"Element,Component,Componente,Service","technology":"Business Logic"},{"description":"Porta de saída que grava no read model.","documentation":{},"id":"34","name":"ProfileWriter","properties":{"structurizr.dsl.identifier":"consRepo"},"tags":"Element,Component,Componente,Repository","technology":"Port/Adapter"},{"description":"Publica eventos de perfil atualizado para outros domínios.","documentation":{},"id":"35","name":"UpdateEventPublisher","properties":{"structurizr.dsl.identifier":"consPublisher"},"tags":"Element,Component,Componente,Producer","technology":"Kafka Producer"}],"description":"Microsserviço que consome eventos, aplica regras de reconciliação e atualiza o read model.","documentation":{},"id":"31","name":"Consolidador de Dados","properties":{"structurizr.dsl.identifier":"consolidator"},"relationships":[{"description":"Consome eventos","destinationId":"41","id":"92","sourceId":"31","tags":"Relationship","technology":"Kafka Consumer"},{"description":"Atualiza perfil","destinationId":"23","id":"93","sourceId":"31","tags":"Relationship","technology":"MongoDB/Cassandra write"},{"description":"Emite métricas e logs","destinationId":"42","id":"94","sourceId":"31","tags":"Relationship","technology":"OTel"},{"description":"Consulta feature flags para regras de consolidação","destinationId":"8","id":"95","sourceId":"31","tags":"Relationship","technology":"HTTP/REST"},{"description":"Valida schemas de eventos","destinationId":"7","id":"96","sourceId":"31","tags":"Relationship","technology":"HTTP/REST"}],"tags":"Element,Container,Aplicacao","technology":"Java + Spring Boot"},{"description":"Adaptador que captura mudanças no Salesforce (CDC/Webhook) e publica eventos de domínio.","documentation":{},"id":"39","name":"Conector CRM","properties":{"structurizr.dsl.identifier":"conectorCrm"},"relationships":[{"description":"Ouvir CDC/Webhook","destinationId":"4","id":"98","sourceId":"39","tags":"Relationship","technology":"REST/SOAP"},{"description":"Publica eventos de domínio","destinationId":"41","id":"100","sourceId":"39","tags":"Relationship","technology":"Kafka Producer"},{"description":"Registra e valida schemas","destinationId":"7","id":"101","sourceId":"39","tags":"Relationship","technology":"HTTP/REST"}],"tags":"Element,Container,Integracao","technology":"Java + Spring Boot"},{"description":"Adaptadores diversos para capturar mudanças em sistemas legados (CDC, fila, SOAP).","documentation":{},"id":"40","name":"Conector Legado","properties":{"structurizr.dsl.identifier":"conectorLegado"},"relationships":[{"description":"Captura mudanças via CDC/Fila","destinationId":"5","id":"102","sourceId":"40","tags":"Relationship","technology":"SOAP/REST/Files"},{"description":"Publica eventos","destinationId":"41","id":"104","sourceId":"40","tags":"Relationship","technology":"Kafka Producer"},{"description":"Registra e valida schemas","destinationId":"7","id":"105","sourceId":"40","tags":"Relationship","technology":"HTTP/REST"}],"tags":"Element,Container,Integracao","technology":"Java + Spring Boot"},{"description":"Plataforma de mensageria/event streaming usada para publicar e consumir eventos de cliente.","documentation":{},"id":"41","name":"Event Bus","properties":{"structurizr.dsl.identifier":"eventBus"},"tags":"Element,Container,Mensageria","technology":"Kafka"},{"components":[{"description":"Recebe traces, métricas e logs de todos os serviços e exporta para backends.","documentation":{},"id":"43","name":"OpenTelemetry Collector","properties":{"structurizr.dsl.identifier":"otelCollector"},"relationships":[{"description":"exporta métricas","destinationId":"44","id":"49","sourceId":"43","tags":"Relationship","technology":"OTLP/HTTP"},{"description":"exporta traces","destinationId":"46","id":"50","sourceId":"43","tags":"Relationship","technology":"OTLP/gRPC"},{"description":"exporta logs","destinationId":"47","id":"51","sourceId":"43","tags":"Relationship","technology":"OTLP/HTTP"}],"tags":"Element,Component,Componente,Observabilidade","technology":"OTel Collector"},{"description":"Armazena métricas de séries temporais e executa queries PromQL.","documentation":{},"id":"44","name":"Prometheus","properties":{"structurizr.dsl.identifier":"prometheus"},"relationships":[{"description":"envia alertas","destinationId":"48","id":"52","sourceId":"44","tags":"Relationship","technology":"Alertmanager API"}],"tags":"Element,Component,Componente,Observabilidade","technology":"Prometheus"},{"description":"Dashboards e visualizações de métricas, logs e traces.","documentation":{},"id":"45","name":"Grafana","properties":{"structurizr.dsl.identifier":"grafana"},"relationships":[{"description":"consulta métricas","destinationId":"44","id":"53","sourceId":"45","tags":"Relationship","technology":"PromQL"},{"description":"consulta traces","destinationId":"46","id":"54","sourceId":"45","tags":"Relationship","technology":"Jaeger API"},{"description":"consulta logs","destinationId":"47","id":"55","sourceId":"45","tags":"Relationship","technology":"Elasticsearch API"}],"tags":"Element,Component,Componente,Observabilidade","technology":"Grafana"},{"description":"Backend para armazenamento e visualização de traces distribuídos.","documentation":{},"id":"46","name":"Jaeger/Tempo","properties":{"structurizr.dsl.identifier":"jaeger"},"tags":"Element,Component,Componente,Observabilidade","technology":"Jaeger"},{"description":"Armazena logs estruturados e logs de auditoria.","documentation":{},"id":"47","name":"Elasticsearch","properties":{"structurizr.dsl.identifier":"elasticsearch"},"tags":"Element,Component,Componente,Observabilidade","technology":"Elasticsearch"},{"description":"Gerencia alertas e notificações baseadas em regras do Prometheus.","documentation":{},"id":"48","name":"Alertmanager","properties":{"structurizr.dsl.identifier":"alertmanager"},"tags":"Element,Component,Componente,Observabilidade","technology":"Prometheus Alertmanager"}],"description":"Stack de observabilidade (OpenTelemetry Collector, Prometheus, Grafana, Jaeger).","documentation":{},"id":"42","name":"Observability Stack","properties":{"structurizr.dsl.identifier":"observability"},"relationships":[{"description":"Fornece dashboards e alertas","destinationId":"3","id":"108","sourceId":"42","tags":"Relationship","technology":"Grafana/Prometheus"}],"tags":"Element,Container,Observabilidade","technology":"Helm charts"},{"description":"Componentes de segurança como Keycloak proxy ou integração de OAuth2 no gateway.","documentation":{},"id":"56","name":"Security Service","properties":{"structurizr.dsl.identifier":"security"},"tags":"Element,Container,Seguranca","technology":"Keycloak, OAuth2"},{"description":"Suite de testes automatizados que valida o fluxo completo da arquitetura.","documentation":{},"id":"57","name":"E2E Test Suite","properties":{"structurizr.dsl.identifier":"e2eTests"},"relationships":[{"description":"Executa testes de fluxo completo","destinationId":"12","id":"115","sourceId":"57","tags":"Relationship","technology":"HTTP/REST"},{"description":"Insere dados de teste","destinationId":"4","id":"116","sourceId":"57","tags":"Relationship","technology":"REST API"},{"description":"Verifica eventos publicados","destinationId":"41","id":"117","sourceId":"57","tags":"Relationship","technology":"Kafka Consumer"}],"tags":"Element,Container,Testes","technology":"JUnit + TestContainers"}],"description":"Sistema responsável por consolidar e consultar dados de cliente.","documentation":{},"id":"11","name":"Plataforma de Consulta de Cliente","properties":{"structurizr.dsl.identifier":"consulta"},"relationships":[{"description":"Consulta feature flags","destinationId":"8","id":"89","linkedRelationshipId":"88","sourceId":"11","technology":"HTTP/REST"},{"description":"Obtém chaves de criptografia","destinationId":"10","id":"91","linkedRelationshipId":"90","sourceId":"11","technology":"HTTP/REST"},{"description":"Valida schemas de eventos","destinationId":"7","id":"97","linkedRelationshipId":"96","sourceId":"11","technology":"HTTP/REST"},{"description":"Ouvir CDC/Webhook","destinationId":"4","id":"99","linkedRelationshipId":"98","sourceId":"11","technology":"REST/SOAP"},{"description":"Captura mudanças via CDC/Fila","destinationId":"5","id":"103","linkedRelationshipId":"102","sourceId":"11","technology":"SOAP/REST/Files"},{"description":"Fornece dashboards e alertas","destinationId":"3","id":"109","linkedRelationshipId":"108","sourceId":"11","technology":"Grafana/Prometheus"}],"tags":"Element,Software System,SistemaPrincipal"}]},"name":"Vivo Customer Data Consolidation","properties":{"structurizr.inspection.info":"0","structurizr.inspection.ignore":"0","structurizr.inspection.error":"11","structurizr.inspection.warning":"0"},"views":{"componentViews":[{"automaticLayout":{"applied":false,"edgeSeparation":0,"implementation":"Graphviz","nodeSeparation":300,"rankDirection":"LeftRight","rankSeparation":300,"vertices":false},"containerId":"13","description":"Componentes internos do Customer Query Service (BFF), incluindo cache L2.","elements":[{"id":"14","x":0,"y":0},{"id":"15","x":0,"y":0},{"id":"16","x":0,"y":0},{"id":"17","x":0,"y":0},{"id":"18","x":0,"y":0}],"externalContainerBoundariesVisible":false,"key":"CustomerQueryComponents","name":"Component View: Plataforma de Consulta de Cliente - Customer Query Service","order":4,"relationships":[{"id":"19"},{"id":"20"},{"id":"21"},{"id":"22"}]},{"automaticLayout":{"applied":false,"edgeSeparation":0,"implementation":"Graphviz","nodeSeparation":300,"rankDirection":"LeftRight","rankSeparation":300,"vertices":false},"containerId":"31","description":"Componentes internos do Consolidador de Dados.","elements":[{"id":"32","x":0,"y":0},{"id":"33","x":0,"y":0},{"id":"34","x":0,"y":0},{"id":"35","x":0,"y":0}],"externalContainerBoundariesVisible":false,"key":"ConsolidatorComponents","name":"Component View: Plataforma de Consulta de Cliente - Consolidador de Dados","order":5,"relationships":[{"id":"36"},{"id":"37"},{"id":"38"}]},{"automaticLayout":{"applied":false,"edgeSeparation":0,"implementation":"Graphviz","nodeSeparation":300,"rankDirection":"LeftRight","rankSeparation":300,"vertices":false},"containerId":"42","description":"Componentes internos do Observability Stack, mostrando coleta, armazenamento e visualização de telemetria.","elements":[{"id":"43","x":0,"y":0},{"id":"44","x":0,"y":0},{"id":"45","x":0,"y":0},{"id":"46","x":0,"y":0},{"id":"47","x":0,"y":0},{"id":"48","x":0,"y":0}],"externalContainerBoundariesVisible":false,"key":"ObservabilityComponents","name":"Component View: Plataforma de Consulta de Cliente - Observability Stack","order":6,"relationships":[{"id":"49"},{"id":"50"},{"id":"51"},{"id":"52"},{"id":"53"},{"id":"54"},{"id":"55"}]},{"automaticLayout":{"applied":false,"edgeSeparation":0,"implementation":"Graphviz","nodeSeparation":300,"rankDirection":"LeftRight","rankSeparation":300,"vertices":false},"containerId":"23","description":"Componentes internos do Customer Profile Store, mostrando estratégia de cache multinível e sharding.","elements":[{"id":"24","x":0,"y":0},{"id":"25","x":0,"y":0},{"id":"26","x":0,"y":0},{"id":"27","x":0,"y":0}],"externalContainerBoundariesVisible":false,"key":"ReadModelComponents","name":"Component View: Plataforma de Consulta de Cliente - Customer Profile Store","order":7,"relationships":[{"id":"28"},{"id":"29"},{"id":"30"}]}],"configuration":{"branding":{},"styles":{"elements":[{"background":"#b3cde0","shape":"Cylinder","tag":"Banco"},{"background":"#90ee90","tag":"Cache"},{"background":"#85bbe0","shape":"Component","tag":"Componente"},{"background":"#438dd5","color":"#ffffff","shape":"RoundedBox","tag":"Container"},{"background":"#4f6581","color":"#ffffff","tag":"Gateway"},{"background":"#a9a9a9","color":"#ffffff","tag":"Infraestrutura"},{"background":"#e2a03d","shape":"Cylinder","tag":"Mensageria"},{"background":"#6b9ac4","tag":"Observabilidade"},{"background":"#ffdb99","shape":"Person","tag":"Pessoa"},{"background":"#8e6e95","tag":"Seguranca"},{"background":"#999999","color":"#ffffff","shape":"Box","tag":"SistemaExterno"},{"background":"#1168bd","color":"#ffffff","shape":"RoundedBox","tag":"SistemaPrincipal"},{"background":"#ffb6c1","tag":"Testes"}],"relationships":[{"color":"#707070","tag":"Relationship","thickness":2}]},"terminology":{}},"containerViews":[{"automaticLayout":{"applied":false,"edgeSeparation":0,"implementation":"Graphviz","nodeSeparation":300,"rankDirection":"LeftRight","rankSeparation":300,"vertices":false},"description":"Visão de containers do sistema de consulta, incluindo novos containers para cache L2 e testes E2E.","elements":[{"id":"1","x":0,"y":0},{"id":"2","x":0,"y":0},{"id":"3","x":0,"y":0},{"id":"4","x":0,"y":0},{"id":"5","x":0,"y":0},{"id":"6","x":0,"y":0},{"id":"7","x":0,"y":0},{"id":"8","x":0,"y":0},{"id":"9","x":0,"y":0},{"id":"10","x":0,"y":0},{"id":"12","x":0,"y":0},{"id":"13","x":0,"y":0},{"id":"23","x":0,"y":0},{"id":"31","x":0,"y":0},{"id":"39","x":0,"y":0},{"id":"40","x":0,"y":0},{"id":"41","x":0,"y":0},{"id":"42","x":0,"y":0},{"id":"56","x":0,"y":0},{"id":"57","x":0,"y":0}],"externalSoftwareSystemBoundariesVisible":false,"key":"Containers","name":"Container View: Plataforma de Consulta de Cliente","order":3,"relationships":[{"id":"100"},{"id":"101"},{"id":"102"},{"id":"104"},{"id":"105"},{"id":"106"},{"id":"108"},{"id":"110"},{"id":"111"},{"id":"113"},{"id":"114"},{"id":"115"},{"id":"116"},{"id":"117"},{"id":"80"},{"id":"82"},{"id":"84"},{"id":"85"},{"id":"86"},{"id":"87"},{"id":"88"},{"id":"90"},{"id":"92"},{"id":"93"},{"id":"94"},{"id":"95"},{"id":"96"},{"id":"98"}],"softwareSystemId":"11"}],"deploymentViews":[{"automaticLayout":{"applied":false,"edgeSeparation":0,"implementation":"Graphviz","nodeSeparation":300,"rankDirection":"LeftRight","rankSeparation":300,"vertices":false},"description":"Visão de deployment com estratégia Blue/Green e componentes de perímetro de segurança.","elements":[{"id":"58","x":0,"y":0},{"id":"59","x":0,"y":0},{"id":"60","x":0,"y":0},{"id":"61","x":0,"y":0},{"id":"62","x":0,"y":0},{"id":"65","x":0,"y":0},{"id":"66","x":0,"y":0},{"id":"67","x":0,"y":0},{"id":"68","x":0,"y":0},{"id":"69","x":0,"y":0},{"id":"70","x":0,"y":0},{"id":"71","x":0,"y":0},{"id":"72","x":0,"y":0},{"id":"73","x":0,"y":0},{"id":"74","x":0,"y":0},{"id":"75","x":0,"y":0},{"id":"76","x":0,"y":0},{"id":"77","x":0,"y":0}],"environment":"Production","key":"BlueGreenDeployment","name":"Deployment View: Production","order":8,"relationships":[{"id":"63"},{"id":"64"},{"id":"78"},{"id":"79"}]}],"systemContextViews":[{"automaticLayout":{"applied":false,"edgeSeparation":0,"implementation":"Graphviz","nodeSeparation":300,"rankDirection":"LeftRight","rankSeparation":300,"vertices":false},"description":"Contexto do sistema de consulta de cliente e suas interações com sistemas externos e ferramentas de infraestrutura.","elements":[{"id":"1","x":0,"y":0},{"id":"2","x":0,"y":0},{"id":"3","x":0,"y":0},{"id":"4","x":0,"y":0},{"id":"5","x":0,"y":0},{"id":"6","x":0,"y":0},{"id":"7","x":0,"y":0},{"id":"8","x":0,"y":0},{"id":"9","x":0,"y":0},{"id":"10","x":0,"y":0},{"id":"11","x":0,"y":0}],"enterpriseBoundaryVisible":true,"key":"SystemContext","name":"System Context View: Plataforma de Consulta de Cliente","order":2,"relationships":[{"id":"103"},{"id":"107"},{"id":"109"},{"id":"112"},{"id":"81"},{"id":"83"},{"id":"89"},{"id":"91"},{"id":"97"},{"id":"99"}],"softwareSystemId":"11"}],"systemLandscapeViews":[{"automaticLayout":{"applied":false,"edgeSeparation":0,"implementation":"Graphviz","nodeSeparation":300,"rankDirection":"LeftRight","rankSeparation":300,"vertices":false},"description":"Visão de landscape dos sistemas relevantes, incluindo ferramentas de suporte à arquitetura.","elements":[{"id":"1","x":0,"y":0},{"id":"2","x":0,"y":0},{"id":"3","x":0,"y":0},{"id":"4","x":0,"y":0},{"id":"5","x":0,"y":0},{"id":"6","x":0,"y":0},{"id":"7","x":0,"y":0},{"id":"8","x":0,"y":0},{"id":"9","x":0,"y":0},{"id":"10","x":0,"y":0},{"id":"11","x":0,"y":0}],"enterpriseBoundaryVisible":true,"key":"Landscape","name":"System Landscape View","order":1,"relationships":[{"id":"103"},{"id":"107"},{"id":"109"},{"id":"112"},{"id":"81"},{"id":"83"},{"id":"89"},{"id":"91"},{"id":"97"},{"id":"99"}]}]}}