> ## 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 com que o Lender é construído: cinco domínios, o perfil de jurisdição que fornece cada regra de mercado, o pipeline de request e o outbox que leva o dinheiro ao ledger. 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 *** | Domínio | Do que é dono | Onde ele para | | --------------- | -------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | | **Products** | Produtos de empréstimo, versões do produto, templates de encargos, tabelas de taxa flutuante. | Uma versão nunca muda. Termos novos são uma versão nova. | | **Origination** | O ciclo de vida da proposta, e o cronograma que o desembolso produz. | Ele registra a intenção de contabilizar. Ele não escreve no ledger. | | **Servicing** | A conta de empréstimo ativa: versões de cronograma, repagamentos, pagamentos antecipados, reprogramações, correções. | Ele nunca edita o histórico. Uma correção é uma transação nova. | | **Accounting** | Perfis contábeis, regras de posting, intenções de posting, rotinas de apropriação, referências de lançamento. | Ele monta postings balanceados. O relay os entrega. | | **Audit** | A trilha do que aconteceu com uma conta de empréstimo. | Somente acréscimo. Nada reescreve um evento. | 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](/pt/lender/jurisdictions). ## Como um request é resolvido *** Cada request passa pelas mesmas três portas antes de um handler rodar. O Lender espera um JWT bearer. As duas leituras de descoberta de jurisdições são as únicas operações públicas. O tenant vem da identidade validada. Ele nunca é um header, um campo do body nem um parâmetro de rota, então quem chama não consegue escolher um tenant. O Lender lê o vínculo de jurisdição do tenant e coloca o perfil correspondente no contexto do request. A busca fica em cache por cinco minutos, então uma mudança de vínculo passa a valer dentro dessa janela. 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](/pt/lender/lender-in-the-platform) cobre a rota completa, incluindo o que o perfil contábil contribui. ## O que o serviço expõe *** | Superfície | Propósito | | -------------------------------- | -------------------------------------------------------------------------------------------------- | | `/api/v1/...` | Toda a API do produto, descrita por um único documento OpenAPI. | | `/health`, `/readyz`, `/version` | Liveness, prontidão de dependências e metadados do 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 tempo de execução. | Leia a [referência de saúde e prontidão](/pt/reference/health-and-readiness) para o contrato de sondas compartilhado pelos produtos Lerian. ## Armazenamentos *** | Dependência | Papel | | --------------- | ------------------------------------------------------------------------------------------------------ | | PostgreSQL | Todas as tabelas de domínio, e o outbox. Dois conjuntos de migrações se aplicam: o core e o do 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 posting. | [Configuração e implantação](/pt/lender/configuration-and-deploy) 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](/pt/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 todo o produto compartilha. A rota de posting, o catálogo de eventos e o isolamento de tenants. Dependências, o contêiner e os ajustes que moldam um deploy.