Arquitetura do Lender

O Lender é um único serviço. Dentro dele, cinco domínios são donos da jornada de crédito, um perfil de jurisdição fornece cada regra específica do mercado, e o dinheiro chega ao ledger por uma fila durável em vez de uma chamada em linha. Esses três fatos explicam quase tudo o que vem a seguir.

​

Cinco domínios, um serviço

---

Cada domínio é dono das próprias tabelas e das próprias operações. O identificador da conta de empréstimo é a chave que une todos. O Lender não gera esse identificador — você o fornece quando desembolsa, e a partir daí cada domínio endereça o empréstimo por ele.

​

A costura de jurisdição

---

As regras de crédito diferem por mercado, então nenhum domínio nomeia um mercado. Tudo que é específico do mercado chega por um perfil de jurisdição, que fornece um conjunto fixo de capacidades:

• O motor de impostos que calcula as retenções no desembolso e os impostos sobre receita na apropriação.
• O calendário de feriados e a convenção de contagem de dias.
• O método de custo efetivo por trás da divulgação de custo.
• O registro de tetos que guarda os limites regulados de taxas e encargos.
• As divulgações que o mercado exige.
• O pipeline de desembolso que roda dentro da transação de desembolso.
• O validador de produtos e a extensão de pré-visualização de cronograma.
• As políticas de ator que decidem quem pode aprovar e quem pode desembolsar.

Os perfis são compilados dentro do serviço em vez de configurados em tempo de execução. Hoje existem dois: BR para o Brasil, e XX, uma base genérica sem impostos e sem tetos. A tabela de jurisdições no banco de dados é uma projeção do que o serviço carrega, então nenhuma chamada de API cria uma jurisdição. Veja Jurisdições.

​

Como um request é resolvido

---

Cada request passa pelas mesmas três portas antes de um handler rodar. Vincule cada tenant a uma jurisdição antes de ele enviar tráfego. O Lender recusa um request de um tenant sem vínculo.

​

O dinheiro sai pelo outbox

---

O Lender nunca contabiliza no ledger durante o seu request. A rota tem quatro propriedades que vale conhecer:

1. Um desembolso, uma apropriação de juros e uma cotação de pagamento antecipado brasileira liquidada escrevem cada um uma intenção de posting na mesma transação de banco de dados que a linha de negócio. Uma queda entre as duas não é possível.
2. Um dispatcher lê a intenção do outbox e a repassa ao Midaz.
3. Cada intenção carrega uma chave de idempotência determinística, então um relay reexecutado colapsa em uma única transação do ledger.
4. O routing falha fechado. Um posting é contabilizado na organização e no ledger que o perfil contábil resolve, e um deploy single-tenant pode cair no default configurado. Quando nenhum destino é resolvido, o Lender não contabiliza nada.

Configure o endpoint do ledger e as credenciais dele antes de esperar contabilizações. Até elas resolverem, as intenções aguardam no outbox e nada chega ao ledger. O Lender na plataforma cobre a rota completa, incluindo o que o perfil contábil contribui.

​

O que o serviço expõe

---

Leia a referência de saúde e prontidão para o contrato de sondas compartilhado pelos produtos Lerian.

​

Armazenamentos

---

Configuração e implantação lista os ajustes por trás de cada um.

​

Trabalho por tempo

---

Não tudo começa com um request. A rotina de apropriação também roda como job agendado. Cada job fica desligado até você habilitá-lo, e você define o horário dele. Veja Contabilidade e rotinas de apropriação.

​

Próximos passos

---