Estructuración de entidades para volúmenes altos de transacciones
Particionamiento por Organizaciones, Ledgers y Cuentas
Si tu banco procesa millones de transacciones cada día, distribuye la carga de trabajo entre muchas cuentas, ledgers u organizaciones. Por ejemplo, segmenta a los clientes por la inicial del apellido, o asigna un ledger separado a cada región. Cada ledger de Midaz es un libro independiente. Midaz procesa juntas las transacciones de un ledger. Esta división evita que un solo ledger se convierta en un cuello de botella. Midaz escala hacia afuera: los distintos ledgers pueden ejecutarse en instancias separadas o en particiones de base de datos separadas.Operaciones orientadas a bloqueos
Midaz aplica cada lote de saldos de forma atómica en un único script Lua de Redis, de modo que un lote se aplica por completo o se revierte por completo. Midaz maneja la concurrencia de forma optimista: cada saldo lleva una versión, y en las rutas de reembolso de sobregiro, un desajuste de versión aborta todo el lote con el error0174, de modo que quien llama vuelve a leer el estado y reintenta.
La cuenta @external omite las verificaciones de piso de saldo y de sobregiro. Puede volverse negativa sin límite, por lo que las transacciones contra ella nunca fallan por fondos disponibles. Cada transacción de todas formas se confirma de forma atómica. O se aplican todas las operaciones, o no se aplica ninguna.
Escalado horizontal de servicios
Midaz usa una arquitectura de microservicios. Escalas cada componente de forma independiente, por ejemplo el procesamiento de transacciones y las consultas. Empieza en pequeño. A medida que crece la demanda, escala los servicios que lo necesiten. Para cargas altas, despliega varias instancias del servicio de transacciones detrás de un balanceador de carga. Usa el escalado de pods de Kubernetes (K8s).CQRS y réplicas de lectura
Midaz usa CQRS (Command Query Responsibility Segregation) para separar las operaciones de escritura y lectura. Optimizas cada ruta de forma independiente. Enruta las cargas pesadas de informes y consultas hacia réplicas de lectura. Esto mantiene rápidas las confirmaciones de transacciones. Las lecturas no ralentizan las escrituras, y las escrituras no ralentizan las lecturas.Loteo y transacciones N:N
Cuando sea posible, agrupa las operaciones relacionadas en una sola transacción. Esto reduce la sobrecarga. Usa transacciones N:N para trabajo masivo, como pagos en masa. Por ejemplo, un lote de 100 débitos y 100 créditos suele ser más rápido que 100 transacciones separadas. Esto funciona cuando las operaciones pertenecen al mismo conjunto lógico. Midaz procesa estas transacciones N:N en una sola confirmación atómica.Monitoreo y escalado iterativo
Monitorea las métricas clave: latencia de transacciones, throughput, uso de recursos (CPU y memoria) y rendimiento de la base de datos. Usa las herramientas de observabilidad de Midaz (OpenTelemetry y Grafana), o envía las métricas a tu propio stack de monitoreo. Escala hacia afuera o hacia arriba antes de alcanzar un umbral de rendimiento. Midaz es modular y source-available, por lo que despliegas las partes que necesitas.Manejo de operaciones multi-moneda y multi-entidad
Estrategias multi-moneda
Midaz admite transacciones multi-moneda con una cuenta de activo separada para cada moneda. Para escalar bien:- Configura cada activo de moneda que necesites.
- Maneja la lógica específica de cada moneda (como el redondeo y las tasas de conversión) en tu capa de integración.
- Para la conversión frecuente de moneda, como el trading de forex, ejecuta la conversión en un servicio separado. Midaz registra los débitos y créditos, pero un servicio externo de tasas FX suministra las tasas.
- Rara vez necesitas un ledger separado por moneda, a menos que la política lo requiera. En su lugar, usa tipos de cuenta y la API de enrutamiento de transacciones para agrupar cuentas por moneda y así lograr informes claros.
- Si una moneda cubre la mayoría de las transacciones, mantén todas las monedas en el mismo ledger. Si las operaciones multi-moneda se vuelven demasiado complejas, sepáralas en un ledger distinto por grupo de moneda.
Múltiples entidades: consolidación y separación
Para un banco que opera en varios países o entidades legales:- Usa la jerarquía de organizaciones para segmentar entidades. Dale a cada entidad su propia moneda base, activos locales y ledgers.
- Modela las transacciones entre entidades como movimientos externos. Una organización acredita su cuenta externa, y la otra debita la suya.
- Puedes ejecutar varias organizaciones en una sola instancia de Midaz. Asigna suficientes recursos: los microservicios procesan todas las solicitudes juntas, por lo que el volumen total importa.
- Puedes desplegar una instancia separada de Midaz por cada entidad aislada, pero pierdes la visibilidad unificada. Un solo clúster con separación interna de organizaciones suele ser más práctico.
Buenas prácticas de optimización de rendimiento
Indexación y consultas
Usa las APIs de Midaz para leer datos, no consultas directas a la base de datos. Estas APIs incluyen índices predefinidos para los identificadores principales: cuentas, portafolios y transacciones.Indexación de campos de metadatos personalizados
Midaz no crea ningún índice predeterminado en las colecciones de metadatos. Los documentos de metadatos usanentity_id como clave. Crea explícitamente los índices que necesites mediante la API de índice de metadatos.
Por defecto, Midaz no indexa los campos de metadatos personalizados. Los clientes completan estos campos libremente como pares clave-valor.
Las consultas o filtros frecuentes en campos no indexados pueden desencadenar escaneos completos de la colección. Estos escaneos se vuelven más lentos a medida que crece el volumen de datos.
Crea un índice cuando uses regularmente un campo de metadatos personalizado en filtros de búsqueda u orden de clasificación. Con un índice, MongoDB encuentra los documentos rápido y reduce el tiempo de respuesta de las consultas.
Recomendaciones:
- Indexa solo los campos de metadatos que consultas u ordenas con frecuencia.
- No indexes los campos de acceso poco frecuente, porque cada índice adicional agrega sobrecarga de escritura.