> ## 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. # Mejores prácticas de producción de Midaz > Configura Midaz para producción con despliegue multi-AZ, autoescalado, servicios administrados y los patrones de resiliencia en Kubernetes recomendados. Midaz corre en producción a alto volumen. Esta guía te da los patrones de despliegue, alta disponibilidad y observabilidad que Lerian recomienda. Síguelos para mantener bajo el tiempo de inactividad y proteger tus datos. ## Configuración óptima *** Empieza un despliegue de producción con estas decisiones: * Despliega en varias zonas de disponibilidad. * Ejecuta al menos 3 nodos de trabajo con autoescalado. * Separa las cargas de aplicación y de base de datos. * Usa servicios administrados como RDS, ElastiCache y MongoDB Atlas. * Aplica patrones de Kubernetes para resiliencia, seguridad y observabilidad. * Automatiza los respaldos y las alertas desde el primer día. ## Planificación de infraestructura *** ### Arquitectura del clúster Planifica el clúster para resiliencia y rendimiento: * Despliega en varias zonas de disponibilidad. * Ejecuta al menos 3 nodos de trabajo para alta disponibilidad. * Activa el autoescalado de nodos para absorber picos de carga. * Separa las cargas de aplicación y de base de datos cuando sea posible. ### Dimensionamiento de recursos * Ajusta el tamaño de los nodos a la carga esperada. * Da primero suficientes recursos a los servicios críticos. * Aplica cuotas de recursos para evitar la contención. * Monitorea el uso y ajusta el dimensionamiento con el tiempo. ### Almacenamiento * Usa almacenamiento sobre SSD para todos los componentes de base de datos. * Define una clase de almacenamiento para cada proveedor de nube. * Aprovisiona volúmenes con margen para el crecimiento. * Usa almacenamiento replicado o duradero para los datos críticos. ## Arquitectura de base de datos y alta disponibilidad *** Midaz usa CQRS (Command Query Responsibility Segregation) para separar las lecturas de las escrituras. Este diseño te permite escalar cada ruta por separado. ### PostgreSQL * Usa un primario dedicado para las escrituras y réplicas para las lecturas. * Activa la replicación síncrona para los datos críticos. * Configura la conmutación por error automática con Patroni o AWS RDS. * Monitorea el retraso de replicación y la consistencia. * Prefiere servicios administrados como AWS RDS o GCP Cloud SQL. ### Redis / Valkey * Despliega en modo clúster a través de varias zonas. * Activa la conmutación por error automática con el clustering nativo, o una topología Sentinel vía `REDIS_MASTER_NAME`. Verifica la configuración de tu cliente — un servicio administrado (ElastiCache, Memorystore) es el valor por defecto más seguro. * Usa servicios administrados como AWS ElastiCache o GCP Memorystore. ### MongoDB * Usa replica sets con miembros en varias zonas. * Monitorea las transiciones de rol y el retraso. * Programa respaldos regulares. * No escribas en los secundarios a menos que sea intencional. * Usa servicios administrados como MongoDB Atlas o AWS DocumentDB. ## Infraestructura de mensajería *** Midaz opera dos superficies de mensajería, ambas desactivadas por defecto: * **RabbitMQ** transporta el pipeline interno asíncrono de operaciones de saldo (`RABBITMQ_TRANSACTION_BALANCE_OPERATION_*`, se activa con `RABBITMQ_TRANSACTION_ASYNC=true`) más los exchanges heredados de eventos de transacción, sobregiro y auditoría. Usa un servicio administrado de RabbitMQ como AWS MQ o CloudAMQP en producción. * **RedPanda** (vía lib-streaming) es el backbone de eventos hacia adelante. Define `STREAMING_ENABLED=true` y `STREAMING_BROKERS`; los eventos se publican en tópicos `lerian.streaming..`. Los eventos de ciclo de vida de transacción y de sobregiro se publican hoy en ambos transportes durante la ventana de migración. La separación lectura/escritura de CQRS la atienden las réplicas de PostgreSQL (DSNs `DB_*_REPLICA_*`), no consumidores del broker reconstruyendo modelos de lectura. ## Estrategias de alta disponibilidad *** ### Redundancia de servicios * Despliega varias réplicas para cada servicio. * Usa reglas de anti-afinidad para distribuir los servicios entre zonas. * Aplica Pod Disruption Budgets para limitar el tiempo de inactividad durante las actualizaciones. ### Balanceo de carga * Usa controladores de ingress con health checks. * Evita la afinidad de sesión a menos que un servicio la requiera. * Activa el connection draining para despliegues suaves. ## Consideraciones de seguridad *** ### Seguridad de red * Aplica políticas de red de Kubernetes para controlar el tráfico. * Da a cada cuenta de servicio permisos mínimos. * Protege el acceso externo con TLS. * Restringe las interfaces de administración con listas de IP permitidas. ### Gestión de secretos * Usa Kubernetes Secrets para credenciales y tokens. * Rota los secretos con una frecuencia regular. * Nunca escribas secretos en el código de contenedores o archivos de configuración. * Usa un gestor de secretos externo para una postura más fuerte. ## Monitoreo y observabilidad *** ### Métricas * Monitorea los KPIs clave de la aplicación y la infraestructura. * Define umbrales de alerta que lleven a la acción. * Usa dashboards para visibilidad en tiempo real. ### Registro * Centraliza los logs de todos los servicios. * Usa un formato estructurado para filtrar más fácilmente. * Aplica políticas de retención y rotación de logs. * Define alertas basadas en logs para eventos críticos. ### Rastreo * Activa el rastreo distribuido entre servicios. * Muestrea las trazas para equilibrar rendimiento y costo. * Correlaciona las trazas con logs y métricas para una visibilidad completa. ### Alertas * Crea alertas claras y confiables. * Ajusta los umbrales para reducir el ruido. * Enruta cada alerta por el canal correcto. * Mantén runbooks para los problemas recurrentes. ## Estrategia de copias de seguridad *** * Automatiza respaldos regulares para los sistemas críticos. * Almacena los respaldos en más de una ubicación o región. * Prueba el procedimiento de restauración con una frecuencia regular. * Mantén la documentación de respaldo actualizada y accesible. ## Idempotencia *** Protege las operaciones críticas contra el procesamiento duplicado en producción: * Envía una clave de idempotencia en cada solicitud de creación de transacción con el header `X-Idempotency`. * Usa claves explícitas y deterministas ligadas a los IDs de tu negocio (IDs de pedido, referencias de pago), no claves autogeneradas. * Lee el header de respuesta `X-Idempotency-Replayed` para distinguir una transacción nueva de una repetición en caché. * Define el header `X-TTL` en segundos para que coincida con tu ventana de reintentos. El valor por defecto es 300. Usa un valor más corto para los flujos síncronos y uno más largo para los asíncronos. Todos los productos de Lerian soportan idempotencia a través de sus propias convenciones de headers. Para detalles de implementación y una comparación entre productos, consulta [Reintentos e idempotencia](/es/reference/retries-idempotency). ## Notas finales *** Alinea tu infraestructura con la arquitectura de Midaz y obtienes: * Una separación limpia de lectura/escritura con CQRS. * Compatibilidad con servicios de nube administrados. * Un camino claro hacia la observabilidad, la conmutación por error y las operaciones seguras. Revisa tu configuración con una frecuencia regular para mantener esta base sólida a medida que creces. ## ¿Qué sigue? *** ¿Listo para escalar, migrar o endurecer tu entorno de producción? * Lee la [guía de implementación de Midaz](/es/midaz/deployment). * [Contacta a nuestro equipo](https://lerian.studio/contact) para soporte personalizado.