O container
O Lender é construído a partir de um Dockerfile multi-estágio — um builder Go Alpine produzindo um binário estático, copiado para um runtime distroless nonroot — e escuta na porta
8080. Ele é entregue como uma imagem de container que você implanta no seu cluster com o tooling de ciclo de vida padrão da plataforma; esta página não assume nenhum empacotamento específico além da imagem.
Sondas operacionais:
Dependências
Superfície de configuração
A configuração é inteiramente dirigida por ambiente. As chaves abaixo são um subconjunto curado — as que moldam o comportamento — não a lista completa.
Modos multi-tenant
O Lender roda em um de dois modos:
- Single-tenant — um tenant (
DEFAULT_TENANT_ID), um schema de banco de dados e uma organização de ledger e ledger fixados em tempo de construção usados como default de posting. - Multi-tenant (
MULTI_TENANT_ENABLED=true) — persistência schema-por-tenant, um pool de clientes do Midaz por tenant e eventos e postings com escopo por tenant. Nesse modo não há default de ledger por ambiente: o destino de ledger vem por transação do perfil contábil do produto.
Posting no ledger e roteamento fail-closed
Um posting chega ao ledger através de uma intenção de posting durável e um relay assíncrono — a rota completa está em O Lender na plataforma. A propriedade operacionalmente importante: o roteamento falha fechado. Um posting é contabilizado na organização de ledger e no ledger resolvidos a partir do perfil contábil (single-tenant cai de volta ao default por ambiente); se nenhum resolver um destino não vazio, o Lender se recusa a contabilizar em vez de contabilizar num ledger vazio ou errado. No modo multi-tenant, um produto sem perfil contábil portanto não pode fazer posting — que é a salvaguarda pretendida.
Próximos passos
O Lender na plataforma
A rota de posting, o catálogo de eventos e o isolamento de tenants em detalhe.