Estruturando entidades para altos volumes de transações
Particionamento por Organizations, Ledgers e Accounts
Se seu banco processa milhões de transações diariamente, considere distribuir cargas de trabalho entre múltiplas accounts, ledgers ou até organizations. Por exemplo, você poderia segmentar clientes pelas iniciais do sobrenome ou alocar ledgers separados por região. Cada ledger no Midaz funciona como um livro independente — transações dentro de um ledger são processadas juntas. Distribuir a carga dessa forma evita que um único ledger se torne um gargalo. A arquitetura do Midaz suporta scale out, permitindo que diferentes ledgers operem em instâncias separadas ou partições de banco de dados.Operações orientadas a lock
Para prevenir conflitos, transações concorrentes são bloqueadas no nível da conta dentro de cada ledger. Isso segue uma estratégia FIFO (first in, first out) e evita race conditions. A conta@external não usa locks, permitindo operações simultâneas — mas cada uma ainda deve seguir regras de atomicidade (tudo ou nada).
Escalabilidade horizontal de serviços
O Midaz é construído em uma arquitetura de microsserviços, o que significa que diferentes componentes — como processamento de transações e consultas — podem ser escalados independentemente. Comece pequeno, mas conforme a demanda aumentar, escale serviços específicos conforme necessário. Para cargas altas, implante múltiplas instâncias do serviço de processamento de transações atrás de um load balancer e aproveite o scaling de pods do Kubernetes (K8s).CQRS e réplicas de leitura
O Midaz emprega CQRS (Command Query Responsibility Segregation) para separar operações de escrita e leitura, permitindo que cada uma seja otimizada individualmente. Use isso a seu favor: cargas pesadas de relatórios e consultas devem ir para réplicas de leitura, mantendo os commits de transações enxutos e eficientes. Leituras não desaceleram escritas, e vice-versa, garantindo alto throughput.Batching e transações N:N
Quando possível, agrupe múltiplas operações relacionadas em uma única transação para reduzir a sobrecarga de processamento. Use transações N:N para operações em massa, como pagamentos em lote. Por exemplo, processar 100 débitos e 100 créditos em um único lote é frequentemente mais eficiente do que processar 100 transações individuais — desde que pertençam ao mesmo conjunto lógico de operações. O Midaz foi projetado para lidar com transações complexas em escala.Monitoramento e escalabilidade iterativa
Monitore métricas-chave: latência de transações, throughput, uso de recursos (CPU/memória) e desempenho do banco de dados. Use as ferramentas de observabilidade nativas do Midaz (OpenTelemetry + Grafana) ou integre com o monitoramento da sua infraestrutura. Escale horizontalmente (ou verticalmente) de forma proativa ao se aproximar dos limites de desempenho. Como o Midaz é modular e open-source, você tem a flexibilidade para implantar conforme necessário.Lidando com operações multi-moeda e multi-entidade
Estratégias multi-moeda
O Midaz suporta transações multi-moeda mantendo contas de assets separadas por moeda. Para otimizar a escalabilidade:- Certifique-se de que todos os assets de moeda necessários estejam configurados.
- Considere a lógica específica de cada moeda (ex.: arredondamento, taxas de conversão) na sua camada de integração.
- Se a conversão de moeda é frequente (ex.: trading forex), gerencie-a em um módulo ou serviço separado — potencialmente usando nosso plugin Exchange Engine. O Midaz lidará com débitos/créditos, mas um serviço externo de taxas FX pode ser necessário.
- Ledgers separados por moeda geralmente não são necessários, a menos que a política exija. Em vez disso, use as APIs de account types e transaction routing para categorizar contas por moeda para clareza nos relatórios.
- Se uma única moeda (ex.: moeda local) é usada na grande maioria das transações, é melhor manter todas as moedas dentro do mesmo ledger. No entanto, se gerenciar operações em múltiplas moedas se tornar muito complexo, considere dividir em ledgers separados por grupo de moedas.
Múltiplas entidades: Consolidação e separação
Para bancos operando em múltiplos países ou entidades legais:- Use a hierarquia de organizations para segmentar entidades, com cada uma tendo sua própria moeda base, assets locais e ledgers.
- Transações entre entidades são tratadas como movimentos externos — uma organization credita sua external account enquanto outra debita a sua própria.
- Rodar múltiplas organizations na mesma instância do Midaz é viável, mas garanta que recursos suficientes estejam alocados. Os microsserviços processam todas as requisições coletivamente, então o volume total importa.
- Implantar instâncias separadas do Midaz para entidades isoladas é possível, mas limita a visibilidade unificada. Tipicamente, um único cluster Midaz com separação interna de organizations é mais prático.
Melhores práticas de otimização de desempenho
Indexação e consultas
Use as APIs do Midaz para recuperação de dados em vez de consultas diretas ao banco de dados. Essas APIs são otimizadas com índices predefinidos para identificadores centrais, como accounts, Portfólios e transactions.Indexação de campos de metadata personalizados
As coleções de metadata já incluem índices para chaves de identificação definidas pelo sistema, garantindo operações internas eficientes. No entanto, campos de metadata personalizados — que os clientes podem preencher livremente como pares chave-valor — não são indexados por padrão. Consultas ou filtros frequentes em campos de metadata não indexados podem resultar em varreduras completas da coleção, impactando o desempenho conforme o volume de dados cresce. Crie índices quando um campo de metadata personalizado é usado regularmente em filtros de busca ou critérios de ordenação. Com um índice adequado, o MongoDB pode localizar documentos de forma eficiente usando estruturas de dados otimizadas, reduzindo significativamente os tempos de resposta das consultas. Recomendações:- Crie índices apenas para campos de metadata frequentemente usados em consultas ou ordenação.
- Evite indexar campos raramente acessados, pois cada índice adicional aumenta a sobrecarga de escrita.