Skip to main content
O Midaz roda em produção com alto volume. Este guia apresenta os padrões de deploy, alta disponibilidade e observabilidade que a Lerian recomenda. Siga-os para manter o downtime baixo e proteger seus dados.

​
Configuração ideal

Comece um deploy de produção com estas escolhas:
  • Faça o deploy em várias zonas de disponibilidade.
  • Rode pelo menos 3 worker nodes com autoscaling.
  • Separe as cargas de trabalho de aplicação e de banco de dados.
  • Use serviços gerenciados como RDS, ElastiCache e MongoDB Atlas.
  • Aplique padrões do Kubernetes para resiliência, segurança e observabilidade.
  • Automatize backups e alertas desde o primeiro dia.

​
Planejamento de infraestrutura

​
Arquitetura do cluster

Planeje o cluster para resiliência e desempenho:
  • Faça o deploy em várias zonas de disponibilidade.
  • Rode pelo menos 3 worker nodes para alta disponibilidade.
  • Habilite o autoscaling de nodes para absorver picos de carga.
  • Separe as cargas de trabalho de aplicação e de banco de dados sempre que possível.

​
Dimensionamento de recursos

  • Ajuste o tamanho dos nodes à carga de trabalho esperada.
  • Dê recursos suficientes primeiro aos serviços críticos.
  • Aplique cotas de recursos para evitar contenção.
  • Monitore o uso e ajuste o dimensionamento ao longo do tempo.

​
Armazenamento

  • Use armazenamento baseado em SSD para todos os componentes de banco de dados.
  • Defina uma storage class para cada provedor de nuvem.
  • Provisione volumes com margem para crescimento.
  • Use armazenamento replicado ou durável para dados críticos.

​
Arquitetura de banco de dados e alta disponibilidade

O Midaz usa CQRS (Command Query Responsibility Segregation) para separar leituras de escritas. Esse design permite escalar cada caminho de forma independente.

​
PostgreSQL

  • Use um primary dedicado para escritas e replicas para leituras.
  • Habilite replicação síncrona para dados críticos.
  • Configure failover automático com Patroni ou AWS RDS.
  • Monitore o lag de replicação e a consistência.
  • Prefira serviços gerenciados como AWS RDS ou GCP Cloud SQL.

​
Redis / Valkey

  • Faça o deploy em modo cluster em várias zonas.
  • Habilite failover automático com clustering nativo, ou uma topologia Sentinel via REDIS_MASTER_NAME. Verifique a configuração do seu cliente. Um serviço gerenciado (ElastiCache, Memorystore) é a opção padrão mais segura.
  • Use serviços gerenciados como AWS ElastiCache ou GCP Memorystore.

​
MongoDB

  • Use replica sets com membros em várias zonas.
  • Monitore as transições de papel e o lag.
  • Agende backups regulares.
  • Não escreva em secondaries a menos que seja intencional.
  • Use serviços gerenciados como MongoDB Atlas ou AWS DocumentDB.

​
Infraestrutura de mensageria

O Midaz roda duas superfícies de mensageria. O streaming compatível com Kafka e o processamento assíncrono de transações ficam desativados por padrão. Os publishers legados de overdraft e auditoria do RabbitMQ ficam habilitados em runtime, a menos que você defina explicitamente suas flags como false. A configuração de exemplo empacotada define essas flags como false:
  • O RabbitMQ carrega o pipeline interno assíncrono de operação de saldo da transação (RABBITMQ_TRANSACTION_BALANCE_OPERATION_*, habilitado com RABBITMQ_TRANSACTION_ASYNC=true), além dos exchanges legados de saída de overdraft e auditoria. Use um serviço RabbitMQ gerenciado, como AWS MQ ou CloudAMQP, em produção.
  • O RedPanda (via lib-streaming) é a espinha dorsal de eventos. Defina STREAMING_ENABLED=true, STREAMING_BROKERS e a fonte exata do roster: ledger para ledger, CRM e Fees, ou tracer para o Tracer. Os fatos publicam em lerian.streaming.ledger ou lerian.streaming.tracer. O roteamento é feito pelos headers do CloudEvents. Os fatos de ciclo de vida da transação publicam por essa superfície.
A separação de leitura/escrita do CQRS é atendida por replicas do PostgreSQL (DSNs DB_*_REPLICA_*), não por consumers do broker reconstruindo read models.

​
Estratégias de alta disponibilidade

​
Redundância de serviço

  • Faça o deploy de várias replicas para cada serviço.
  • Use regras de anti-affinity para distribuir os serviços entre zonas.
  • Aplique Pod Disruption Budgets para limitar o downtime durante atualizações.

​
Balanceamento de carga

  • Use ingress controllers com health checks.
  • Evite session affinity, a menos que um serviço exija.
  • Habilite connection draining para rollouts suaves.

​
Considerações de segurança

​
Segurança de rede

  • Aplique network policies do Kubernetes para controlar o tráfego.
  • Dê permissões mínimas a cada service account.
  • Proteja o acesso externo com TLS.
  • Restrinja interfaces administrativas com allowlists de IP.

​
Gerenciamento de secrets

  • Use Kubernetes Secrets para credenciais e tokens.
  • Rotacione os secrets em uma programação regular.
  • Nunca faça hardcode de secrets em containers ou arquivos de configuração.
  • Use um secret manager externo para uma postura mais forte.

​
Monitoramento e observabilidade

​
Métricas

  • Monitore os principais KPIs de aplicação e infraestrutura.
  • Defina limites de alerta que levem à ação.
  • Use dashboards para visibilidade em tempo real.

​
Logging

  • Centralize os logs de todos os serviços.
  • Use um formato estruturado para facilitar a filtragem.
  • Aplique políticas de retenção e rotação de logs.
  • Defina alertas baseados em logs para eventos críticos.

​
Tracing

  • Habilite tracing distribuído entre os serviços.
  • Amostre traces para equilibrar desempenho e custo.
  • Correlacione traces com logs e métricas para visibilidade completa.

​
Alertas

  • Crie alertas claros e confiáveis.
  • Ajuste os limites para reduzir ruído.
  • Roteie cada alerta pelo canal certo.
  • Mantenha runbooks para problemas recorrentes.

​
Estratégia de backup

  • Automatize backups regulares para sistemas críticos.
  • Armazene backups em mais de um local ou região.
  • Teste o procedimento de restauração em uma programação regular.
  • Mantenha a documentação de backup atualizada e acessível.

​
Idempotência

Proteja operações críticas contra processamento duplicado em produção:
  • Envie uma chave de idempotência em cada requisição de criação de transação com o header X-Idempotency.
  • Use chaves explícitas e determinísticas vinculadas aos IDs do seu negócio (IDs de pedido, referências de pagamento), não chaves geradas automaticamente.
  • Leia o header de resposta X-Idempotency-Replayed para distinguir uma transação nova de uma repetição em cache.
  • Defina o header X-TTL em segundos para corresponder à sua janela de nova tentativa. O padrão é 300. Use um valor menor para fluxos síncronos e um maior para fluxos assíncronos.
Todos os produtos da Lerian aceitam idempotência por meio de suas próprias convenções de header. Para detalhes de implementação e uma comparação entre produtos, veja Novas tentativas e idempotência.

​
Notas finais

Alinhe sua infraestrutura à arquitetura do Midaz para obter:
  • Separação limpa de leitura/escrita com CQRS.
  • Compatibilidade com serviços de nuvem gerenciados.
  • Um caminho claro para observabilidade, failover e operações seguras.
Revise sua configuração em uma programação regular.

​
O que vem a seguir?