Pré-requisitos

O Lender precisa de um conjunto pequeno de coisas prontas antes da primeira chamada de API. Esta página lista essas coisas na ordem em que você as configura. Quando cada item aqui estiver pronto, siga o Início rápido para originar um empréstimo.

​

Serviços de que o Lender depende

---

PostgreSQL, Valkey e RedPanda são obrigatórios: o Lender não inicia sem o backbone de eventos. Um provedor de identidade é obrigatório quando a autorização de rota está habilitada, que é o padrão. Produção exige um. Um primeiro empréstimo não precisa de Midaz. Leia Lançamentos no ledger abaixo para saber o que fica esperando.

​

Rode o Lender localmente

---

O Lender é um único serviço Go. Uma execução local precisa do toolchain Go na versão 1.26 ou posterior, Docker com Compose e Make.

​

Aplique as migrations

---

O Lender não migra o banco de dados quando sobe. Você aplica as migrations por fora, a partir de um conjunto no diretório migrations. A imagem do container carrega um binário /migrate que aplica esse conjunto. O conjunto também popula o registro de jurisdições: duas jurisdições ativas, BR para o Brasil e XX, a base genérica. Nenhuma API cria uma jurisdição. O binário em produção carrega o comportamento de cada perfil, e a tabela registra quais códigos esse binário conhece. Leia Jurisdições para saber o que um perfil decide.

​

Configuração obrigatória

---

O outbox em PostgreSQL é obrigatório e é inicializado automaticamente. Configure a autenticação quando o seu deploy habilita a autorização de rota.

​

Um subject autenticado: PLUGIN_AUTH_ENABLED=true, o padrão

O Lender registra quem agiu em cada proposta de empréstimo. Ele lê o analista responsável a partir do subject do token bearer, não do corpo da requisição. Cada chamada de proposta de empréstimo precisa, portanto, de uma identidade autenticada. PLUGIN_AUTH_ENABLED tem true como padrão. Defina PLUGIN_AUTH_HOST com o endereço do seu provedor de identidade. Depois, envie um token bearer em cada chamada. O token precisa de uma claim de subject não vazia, e o mesmo subject deve criar, aprovar e desembolsar a proposta. O Lender define os papéis e as permissões dele em um arquivo de seed. Carregue esse seed no seu provedor de identidade. O papel do analista precisa destas permissões:

​

Um destino durável de lançamento: sempre presente

Um empréstimo desembolsado registra a intenção de lançamento dele de forma durável. O Lender inicializa o outbox transacional em PostgreSQL em cada deploy, na mesma transação de banco de dados que move a proposta para disbursed. OUTBOX_ENABLED não existe. O dispatcher repassa cada intenção depois, na cadência que OUTBOX_DISPATCH_INTERVAL_SEC define. Leia Contabilidade e rodadas de apropriação para saber o que o ledger recebe.

​

Lançamentos no ledger

---

Aponte o Lender para o Midaz quando você quiser que os lançamentos caiam no ledger: O empréstimo é originado com ou sem essas variáveis. Enquanto você não configurar um endpoint de ledger, as intenções de lançamento ficam duráveis no outbox e o lançamento no ledger espera. Configure o ledger antes de esperar contabilizações.

​

Padrões de tenant

---

DEFAULT_TENANT_ID identifica o tenant, e deve ser um UUID válido. As migrations vinculam o tenant padrão, 11111111-1111-1111-1111-111111111111, a BR. Se você definir outro DEFAULT_TENANT_ID, adicione a linha dele em public.tenant_jurisdictions, ou o Lender recusa as requisições dele com 403.

​

Streaming de eventos

---

O Lender não sobe sem o backbone de eventos. Defina STREAMING_ENABLED=true, aponte STREAMING_BROKERS para o RedPanda e defina STREAMING_CLOUDEVENTS_SOURCE=lender. O Lender valida esses valores quando sobe.

​

Checklist

---

• PostgreSQL 17, Valkey 8 e RedPanda acessíveis.
• Migrations aplicadas.
• STREAMING_ENABLED=true e STREAMING_BROKERS definidos.
• Quando a autorização de rota está habilitada, garanta que o provedor de identidade está acessível e use um token bearer com um subject e cada permissão da tabela acima.
• DEFAULT_TENANT_ID um UUID válido.

​

Próximos passos

---