Saltar al contenido principal
Midaz está diseñado para una genuina portabilidad e independencia; puede desplegarlo en cualquier nube pública o privada sin estar atado a un solo proveedor. En su interior, utilizamos una arquitectura de microservicios, que permite que cada componente sea autosuficiente y fácilmente escalable (o reemplazable) a medida que cambian sus requisitos.

​
Arquitectura de microservicios

El siguiente diagrama (Figura 1) muestra cómo encajan las piezas.

Figura 1. Macro-arquitectura de Midaz

​
1. Capa de clúster (gestión del cliente)

Esta capa es gestionada por el cliente y proporciona la base de Kubernetes para ejecutar Midaz. Recomendamos habilitar los siguientes servicios para garantizar un despliegue fluido y seguro:
  • Service: Abstracción de red para exponer y enrutar servicios.
  • AutoScaler: Ajusta automáticamente el número de pods.
  • HPA (Horizontal Pod Autoscaler): Escala aplicaciones basándose en métricas.
  • Secrets: Gestión segura de datos sensibles.
  • ConfigMap: Gestión de configuración externalizada.
Esta capa gobierna y coordina todos los componentes dentro del clúster.

​
2. Capa de front-end

Incluye la Midaz Console, que funciona como la interfaz de usuario para la interacción del sistema (como el panel de administración, dashboards, etc.).

​
3. Capa de back-end

Incluye los dos servicios que forman la base esencial del Midaz Ledger:
  • Onboarding: Maneja la configuración de organizaciones, ledgers, assets, portfolios, segments y accounts.
  • Transactions: Gestiona transacciones financieras, operaciones y movimiento de assets.

​
4. Capa de datos

Esta capa incluye las bases de datos y componentes de infraestructura requeridos para soportar los datos de aplicación y flujos de eventos:
  • PostgreSQL (denominado “Midaz”): Usado como la base de datos relacional principal; incluye una réplica para redundancia o escalado de lectura.
  • Valkey: Un almacén de clave-valor compatible con Redis para caché o recuperación rápida de datos.
  • MongoDB: Probablemente usado para almacenar datos no estructurados o semi-estructurados.
  • RabbitMQ: Broker de mensajes para comunicación asíncrona entre servicios.
Cada uno de estos tiene almacenamiento persistente asociado para durabilidad de datos.

​
5. Capa de Helm Chart

Midaz usa Helm Charts (específicamente lerianstudio/helm) para hacer más sencillo y eficiente el despliegue y configuración de la infraestructura. Sirve como el elemento de conexión entre el código y Kubernetes, asegurando que cada componente se despliegue de manera consistente en diferentes entornos.
ConsejoPara más detalles, consulte la página Desplegar usando Helm.

​
Infraestructura que funciona

En la Arquitectura de Midaz, cada capa está enfocada, sin complejidad innecesaria. Escala naturalmente y se adapta a medida que cambian sus necesidades. Esta configuración no solo es técnicamente sólida; está construida para uso en el mundo real.
  • Kubernetes coordina cómo se comunica cada capa, asegurando interacciones seguras y confiables en todo el sistema.
  • Helm mantiene los despliegues y configuraciones sincronizados, para que el escalado y las actualizaciones ocurran sin fricción.
Debido a que la plataforma es modular, extenderla es simple. Puede agregar nuevos componentes según sea necesario sin interrumpir lo que ya está en su lugar.