Arquitetura

O Midaz pode rodar em ambientes de nuvem pública ou privada. Selecione e opere a infraestrutura que atende aos seus requisitos de deploy. O Midaz usa uma arquitetura modular. O Ledger é organizado em torno de fronteiras de domínio, com infraestrutura de suporte para armazenamento, cache, mensageria e streaming. O Tracer roda como um serviço separado.

​

Fronteira de repositório e deploy

O Midaz entrega dois runtimes em um único repositório e release: o monólito modular do Ledger (com CRM e Fees) e o Tracer. O Tracer não fica embutido no processo do Ledger: faça o deploy dele e escale-o separadamente. O Ledger HTTP v2 pode optar pela interface de reserva unidirecional com o Tracer. O Ledger HTTP v1 nunca a chama. A superfície HTTP pública do Tracer continua sendo /v1, portanto essa interface não cria uma API pública Tracer v2. O Tracer nunca chama o Ledger.

​

Arquitetura modular

---

O diagrama abaixo (Figura 1) mostra como as peças se encaixam.

​

1. Camada de cluster (gerenciada por você)

Você gerencia essa camada. Ela fornece a base Kubernetes que roda o Midaz. Habilite estes serviços:

• Service: abstração de rede para expor e rotear serviços.
• AutoScaler: ajusta automaticamente o número de pods.
• HPA (Horizontal Pod Autoscaler): escala aplicações com base em métricas.
• Secrets: gestão segura de dados sensíveis.
• ConfigMap: gestão de configuração externalizada.

Essa camada governa e coordena todos os componentes dentro do cluster.

​

2. Camada de front-end

A camada de front-end fornece a interface de usuário para a interação com o sistema (painel administrativo, dashboards e outros).

​

3. Camada de back-end

O back-end do Ledger é um monólito modular que concentra as responsabilidades principais do ledger do Midaz. O Midaz também roda o Tracer como um serviço separado. O Ledger reúne quatro componentes principais:

• Domínio Onboarding: gerencia organizações, ledgers, ativos, portfólios, segmentos e contas.
• Domínio Transactions: trata transações financeiras, operações e movimentações de ativos.
• CRM: fica embutido no processo do Ledger.
• Fees: fica embutido no processo do Ledger.

Essa abordagem mantém fronteiras de domínio claras. Ela também simplifica o deploy e reduz a complexidade operacional.

​

4. Camada de dados

Essa camada reúne os bancos de dados e os componentes de infraestrutura que sustentam os dados da aplicação e os fluxos de eventos:

• PostgreSQL: bancos de dados onboarding e transaction separados, cada um com uma conexão primária e uma conexão de réplica opcional.
• Valkey: um armazenamento chave-valor compatível com Redis. O ledger valida e atualiza os saldos em tempo real nele e depois os sincroniza com o PostgreSQL. Ele também faz cache de dados.
• MongoDB: armazena dados semiestruturados: metadados de entidades, holders e instrumentos do CRM e pacotes de tarifas e de cobrança.
• RabbitMQ: broker de mensagens para o processamento assíncrono de transações e as trocas de eventos do ledger.
• Redpanda: broker compatível com Kafka para os streams de eventos do Ledger. O Ledger publica os eventos configurados nele apenas quando você define STREAMING_ENABLED=true e configura os brokers de streaming.

A persistência é específica de cada deploy. A configuração do Compose empacotada não monta um volume de dados para o Redpanda. Configure o armazenamento e a retenção de produção para cada serviço.

​

5. Camada de Helm Chart

O Midaz usa Helm Charts para fazer o deploy e configurar a infraestrutura. O chart conecta o código ao Kubernetes. Ele faz o deploy de cada componente da mesma forma em todos os ambientes.

​

Como as camadas funcionam juntas

---

Cada camada tem um papel específico.

• O Kubernetes coordena como as camadas se comunicam.
• O Helm mantém os deploys e as configurações sincronizados.

Você pode adicionar novos componentes conforme a necessidade, sem interromper o que já está em execução.