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

Configuração ideal


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

Planejamento de infraestrutura


Arquitetura do cluster

Planeje o cluster para resiliência e desempenho:
  • Faça deploy em várias zonas de disponibilidade.
  • Execute pelo menos 3 nós de trabalho para alta disponibilidade.
  • Ative o autoscaling de nós para absorver picos de carga.
  • Separe as cargas de aplicação e de banco de dados quando possível.

Dimensionamento de recursos

  • Ajuste o tamanho dos nós à carga esperada.
  • Dê primeiro recursos suficientes 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 sobre SSD para todos os componentes de banco de dados.
  • Defina uma classe de armazenamento para cada provedor de nuvem.
  • Provisione volumes com margem para o crescimento.
  • Use armazenamento replicado ou durável para os dados críticos.

Arquitetura de banco de dados e alta disponibilidade


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

PostgreSQL

  • Use um primário dedicado para as escritas e réplicas para as leituras.
  • Ative a replicação síncrona para os dados críticos.
  • Configure o failover automático com Patroni ou AWS RDS.
  • Monitore o atraso de replicação e a consistência.
  • Prefira serviços gerenciados como AWS RDS ou GCP Cloud SQL.

Redis / Valkey

  • Faça deploy em modo cluster em várias zonas.
  • Ative o failover automático com o clustering nativo, ou uma topologia Sentinel via REDIS_MASTER_NAME. Verifique a configuração do seu cliente — um serviço gerenciado (ElastiCache, Memorystore) é o padrão mais seguro.
  • 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 atraso.
  • Agende backups regulares.
  • Não escreva nos secundários a menos que seja intencional.
  • Use serviços gerenciados como MongoDB Atlas ou AWS DocumentDB.

Infraestrutura de mensageria


O Midaz opera 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 publicadores legados do RabbitMQ para overdraft e auditoria ficam habilitados em runtime, a menos que suas variáveis sejam definidas explicitamente como false; a configuração de exemplo incluída define essas variáveis como false:
  • RabbitMQ carrega o pipeline interno assíncrono de operações de saldo (RABBITMQ_TRANSACTION_BALANCE_OPERATION_*, ativado com RABBITMQ_TRANSACTION_ASYNC=true) mais exchanges legados de overdraft e auditoria. Use um serviço gerenciado de RabbitMQ como AWS MQ ou CloudAMQP em produção.
  • RedPanda (via lib-streaming) é o backbone de eventos. Defina STREAMING_ENABLED=true, STREAMING_BROKERS e o source exato do roster: ledger para ledger, CRM e Fees, ou tracer para o Tracer. Os fatos são publicados em lerian.streaming.ledger ou lerian.streaming.tracer; roteie pelos cabeçalhos CloudEvents. Fatos do ciclo de vida de transações são publicados por essa superfície.
A separação leitura/escrita do CQRS é atendida pelas réplicas do PostgreSQL (DSNs DB_*_REPLICA_*), não por consumidores do broker reconstruindo modelos de leitura.

Estratégias de alta disponibilidade


Redundância de serviços

  • Faça deploy de várias réplicas para cada serviço.
  • Use regras de anti-afinidade para distribuir os serviços entre zonas.
  • Aplique Pod Disruption Budgets para limitar o tempo de inatividade durante as atualizações.

Balanceamento de carga

  • Use ingress controllers com health checks.
  • Evite a afinidade de sessão a menos que um serviço a exija.
  • Ative o 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ê a cada service account permissões mínimas.
  • Proteja o acesso externo com TLS.
  • Restrinja as interfaces administrativas com listas de IPs permitidos.

Gerenciamento de secrets

  • Use Kubernetes Secrets para credenciais e tokens.
  • Rotacione os secrets com uma frequência regular.
  • Nunca escreva secrets diretamente no código de containers ou arquivos de configuração.
  • Use um gerenciador de secrets externo para uma postura mais forte.

Monitoramento e observabilidade


Métricas

  • Monitore os KPIs principais da aplicação e da infraestrutura.
  • Defina limiares 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 filtrar com mais facilidade.
  • Aplique políticas de retenção e rotação de logs.
  • Defina alertas baseados em logs para eventos críticos.

Tracing

  • Ative o rastreamento distribuído entre serviços.
  • Amostre os rastros para equilibrar desempenho e custo.
  • Correlacione os rastros com logs e métricas para uma visibilidade completa.

Alertas

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

Estratégia de backup


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

Idempotência


Proteja as operações críticas contra o 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 ligadas aos IDs do seu negócio (IDs de pedido, referências de pagamento), não chaves autogeradas.
  • 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 retentativas. O valor padrão é 300. Use um valor mais curto para os fluxos síncronos e um mais longo para os assíncronos.
Todos os produtos da Lerian suportam idempotência através de suas próprias convenções de headers. Para detalhes de implementação e uma comparação entre produtos, consulte Retentativas e idempotência.

Considerações finais


Alinhe sua infraestrutura à arquitetura do Midaz e você ganha:
  • Uma 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 com uma frequência regular para manter essa base sólida à medida que você cresce.

Próximos passos


Pronto para escalar, migrar ou endurecer seu ambiente de produção?