> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Boas práticas de produção do Midaz > Configure o Midaz para produção com deploy multi-AZ, autoscaling, serviços gerenciados e os padrões de resiliência do Kubernetes recomendados pela Lerian. 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](/pt/reference/retries-idempotency). ## 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? *** * Leia o [guia de deploy do Midaz](/pt/products/midaz/deployment). * [Fale com nosso time](https://lerian.studio/contact) para suporte personalizado.