Como arquitetamos 91 microserviços para uma plataforma de saúde digital

Quando chegamos no projeto, a plataforma já tinha alguns serviços rodando, mas sem uma estratégia clara de domínios, comunicação ou deployment. O resultado era o esperado: times pisando um no trabalho do outro, deploys com medo e um RabbitMQ que ninguém sabia ao certo o que estava consumindo.

Ao longo de dois anos, evoluímos a arquitetura para 91 microserviços em produção — cobrindo dois produtos distintos (CARE e Personal Care), integrando múltiplas seguradoras, e servindo milhares de usuários com requisitos rigorosos de disponibilidade e privacidade de dados de saúde.

A decisão mais importante: domínios antes de serviços

O erro mais comum em projetos que "adotam microserviços" é criar serviços por conveniência técnica — "vamos separar o módulo de autenticação", "vamos extrair o envio de e-mail". Isso gera dezenas de serviços sem coesão de negócio, acoplamento alto e um grafo de dependências impossível de entender.

Nossa primeira decisão foi mapear domínios funcionais do negócio e só depois definir os limites dos serviços. No contexto de saúde: usuários, comunicações, agendamento, classificação clínica, dialer, teleconsulta e integrações externas são domínios distintos com equipes e ciclos de deploy independentes.

Event-driven como padrão — não como exceção

Com RabbitMQ como espinha dorsal de comunicação assíncrona, conseguimos desacoplar os serviços ao ponto onde cada um pode ser deployado, escalado ou substituído de forma independente. O CARE platform, por exemplo, usa eventos para orquestrar fluxos complexos: um membro é classificado → comunicação é disparada → dialer agenda uma ligação → consulta é criada — tudo sem chamadas síncronas encadeadas.

• Cada serviço publica eventos de domínio, não comandos diretos para outros serviços
• Dead letter queues para reprocessamento sem perda de mensagens
• Filas com prioridade para operações críticas ao paciente
• Monitoramento de lag de consumo como indicador de saúde do sistema

GitOps com ArgoCD: o deploy que não dá medo

Com 91 serviços, deploy manual é inviável. Adotamos GitOps como estratégia central: cada serviço tem seu manifesto Kubernetes no repositório, e o ArgoCD sincroniza automaticamente o estado desejado com o estado do cluster em GCP. O resultado é auditabilidade total, rollback em segundos e a confiança para fazer deploy a qualquer hora.

Lições que ficaram

• Invista pesado em observabilidade desde o início — sem Grafana e ELK, você está voando cego
• Padronize o scaffolding dos serviços: mesmo structure, mesmo CI/CD, mesma lib de logging
• Trate dados de saúde como primeira classe: PII isolado, criptografia em repouso, consent manager
• Semantic release e versionamento automático evitam quebrar contratos entre serviços
• Nunca subestime o custo operacional de manter 91 serviços saudáveis — automação é sobrevivência