> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Arquitetura do Lender > As partes que formam o Lender: cinco domínios, o perfil de jurisdição que fornece cada regra de mercado, o pipeline de requisições e o outbox que leva dinheiro até o ledger. O Lender é um serviço só. Dentro dele, cinco domínios cuidam da jornada de crédito, um **perfil** de jurisdição fornece cada regra específica de mercado, e o dinheiro chega ao ledger por uma fila durável em vez de uma chamada inline. ## Cinco domínios, um serviço *** | Domínio | O que ele possui | Onde ele para | | ---------------------- | ------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------- | | **Produtos** | Produtos de empréstimo, versões de produto, templates de encargo, tabelas de taxa flutuante. | Uma versão nunca muda. Termos novos são uma versão nova. | | **Originação** | O ciclo de vida da proposta, e o cronograma que o desembolso produz. | Ele registra a intenção de contabilizar. Ele não grava no ledger. | | **Gestão da carteira** | A conta de empréstimo ativa: versões do cronograma, pagamentos, pagamentos antecipados, reprogramações, correções. | Ele nunca edita o histórico. Uma correção é uma transação nova. | | **Contabilidade** | Perfis contábeis, regras de lançamento, intenções de lançamento, rodadas de apropriação, referências de diário. | Ele monta lançamentos balanceados. O relay entrega esses lançamentos. | | **Auditoria** | A trilha do que aconteceu com uma conta de empréstimo. | Apenas acréscimo. Nada reescreve um evento. | Cada domínio possui as próprias tabelas e as próprias operações. O **identificador da conta de empréstimo** é a chave que junta os domínios. O Lender não gera esse identificador. Você fornece o identificador no desembolso, e cada domínio endereça o empréstimo por ele daí em diante. ## O encaixe da jurisdição *** As regras de crédito mudam conforme o mercado, então nenhum domínio nomeia um mercado. Tudo que é específico de mercado chega por um perfil de jurisdição, que fornece um conjunto fixo de capacidades: * O motor de tributos que calcula retenções no desembolso e tributos 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 taxa e de tarifa. * As divulgações que o mercado exige. * O pipeline de desembolso que roda dentro da transação de desembolso. * O validador de produto e a extensão de prévia do cronograma. * As políticas de ator que decidem quem pode aprovar e quem pode desembolsar. Os perfis são compilados no serviço em vez de configurados em runtime. Dois vêm hoje: **BR** para o Brasil e **XX**, uma base genérica sem tributos 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](/pt/products/lender/jurisdictions). ## Como uma requisição é resolvida *** Cada requisição passa pelos mesmos três controles antes de um handler rodar. O Lender espera um JWT bearer. As duas leituras de descoberta de jurisdição são as únicas operações públicas. O tenant vem da identidade validada. Ele nunca é um header, um campo de corpo ou um parâmetro de caminho, então um chamador não consegue escolher um tenant. O Lender lê o vínculo de jurisdição do tenant e põe o perfil correspondente no contexto da requisição. A consulta fica em cache por cinco minutos, então uma troca de vínculo passa a valer dentro dessa janela. Vincule cada tenant a uma jurisdição antes de ele mandar tráfego. O Lender recusa uma requisição de um tenant sem vínculo. ## O dinheiro sai pelo outbox *** O Lender nunca lança no ledger durante a sua requisição. O caminho tem quatro propriedades: 1. Um desembolso, uma apropriação de juros e uma cotação brasileira de pagamento antecipado liquidada gravam, cada um, uma **intenção de lançamento** na mesma transação de banco de dados da linha de negócio. Uma queda entre as duas coisas não é possível. 2. Um dispatcher lê a intenção no outbox e a repassa ao Midaz. 3. Cada intenção carrega uma chave de idempotência determinística, então um repasse repetido colapsa em uma transação só no ledger. 4. O roteamento falha fechado. Um lançamento é contabilizado na organização e no ledger que o perfil contábil resolve, e um deploy single-tenant pode recorrer ao padrão configurado dele. Quando nenhum destino é resolvido, o Lender não lança nada. Configure o endpoint do ledger e as credenciais dele antes de esperar contabilizações. Enquanto eles não resolvem, as intenções esperam no outbox e nada chega ao ledger. [O Lender na plataforma](/pt/products/lender/lender-in-the-platform) cobre o caminho completo, incluindo o que o perfil contábil acrescenta a ele. ## O que o serviço expõe *** | Superfície | Objetivo | | -------------------------------- | --------------------------------------------------------------------------------------------------- | | `/api/v1/...` | Toda a API do produto, descrita por um documento OpenAPI. | | `/health`, `/readyz`, `/version` | Liveness, readiness das dependências e metadados de build. Os três respondem antes da autenticação. | | `/api/v1/streaming/manifest` | O catálogo de eventos que este deploy publica. | | `/api/v1/systemplane/...` | Administração da configuração em runtime. | Leia a [referência de health e readiness](/pt/reference/health-and-readiness) para o contrato de probe compartilhado entre os produtos Lerian. ## Armazenamentos *** | Dependência | Papel | | --------------- | ----------------------------------------------------------------------------------------------------------------- | | PostgreSQL | Cada tabela de domínio, e o outbox. Aplicam-se dois conjuntos de migrations: o conjunto core e o conjunto Brasil. | | Valkey ou Redis | Registros de idempotência, e o cache de jurisdição. | | RedPanda | Eventos de ciclo de vida, quando o streaming está habilitado. | | Midaz | O destino de cada lançamento. | [Configuração e deploy](/pt/products/lender/configuration-and-deploy) lista os ajustes por trás de cada um. ## Trabalho disparado por tempo *** Nem tudo começa com uma requisição. A rodada de apropriação também roda como job agendado. Cada job fica desligado até você habilitar, e você define o agendamento dele. Veja [Contabilidade e rodadas de apropriação](/pt/products/lender/accounting-and-accrual-runs). ## Próximos passos *** Uma proposta de enviada até desembolsada, e a transação que faz o trabalho. O vocabulário que o produto inteiro compartilha. O caminho de lançamento, o catálogo de eventos e o isolamento entre tenants. Dependências, o container e os ajustes que moldam um deploy.