> ## 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. # Casos de uso do Fetcher > Cenários concretos para o Fetcher: centralizar o acesso a bancos de dados entre serviços, alimentar conciliação e relatórios, publicar extrações verificáveis e embarcar a extração na sua própria aplicação. Cada cenário abaixo apresenta primeiro o problema, e depois o que muda quando o Fetcher passa a ser dono do caminho de extração. ## Pare de reconstruir o acesso a bancos de dados em cada serviço *** **O problema.** A Lerian passou por isso internamente. Cada time de produto construiu a própria lógica de acesso a dados contra os mesmos bancos externos, e cada cópia envelheceu separadamente. O Fetcher existe para centralizar esse trabalho. O mesmo padrão aparece em qualquer empresa que roda vários sistemas internos contra os mesmos bancos operacionais. Cada time escreve o próprio pool de conexões, o próprio tratamento de segredos e o próprio construtor de consultas. É o mesmo trabalho, feito cinco vezes. **O que muda.** Um único registro de conexão serve a todos os consumidores. O Fetcher criptografa a senha uma vez, testa a conexão sob demanda e aplica os mesmos dez operadores de filtro aos cinco tipos de banco. Um novo consumidor não registra nenhum driver e não guarda nenhuma credencial. Ele chama uma API. Adicionar um tipo de fonte de dados vira o trabalho de um time, em vez do trabalho de cinco. ## Alimente conciliação e relatórios a partir de bancos operacionais *** **O problema.** Conciliação e geração de relatórios precisam de linhas que vivem fora da plataforma. Essas linhas estão no PostgreSQL operacional de um banco, no MySQL de um parceiro ou em um MongoDB de clientes. O produto consumidor precisa alcançá-las sem virar, ele próprio, um cliente de banco de dados. **O que muda.** O consumidor submete uma seleção de campos por fonte de dados e por tabela. O Fetcher valida essa seleção contra o esquema vivo antes de rodar qualquer coisa. Uma coluna renomeada, portanto, falha no momento do planejamento, e não no meio da extração. O Worker grava o resultado em object storage e publica `job.completed` ou `job.failed`. O consumidor reage ao evento. O Fetcher também resolve um conjunto fixo de fontes de dados internas da Lerian a partir de variáveis de ambiente, então um relatório sobre dados do Midaz não precisa de conexão registrada. ## Publique uma extração que um terceiro consegue verificar *** **O problema.** Você envia uma extração de dados para um auditor, um regulador ou um parceiro. Eles precisam de prova de que o arquivo veio dos seus sistemas e de que ninguém o editou no caminho. **O que muda.** O Worker assina o JSON em texto claro com HMAC-SHA256 antes de criptografar o payload, e depois armazena o resultado com criptografia AES-GCM em repouso. Quem recebe deriva a chave externa de verificação a partir da sua chave-mestra com o comando `make derive-key`, e confere a assinatura de forma independente. Essa chave derivada apenas verifica assinaturas. Ela não descriptografa credenciais armazenadas, e não forja mensagens internas entre o Manager e o Worker. ## Adicione extração a um serviço que você já roda *** **O problema.** Você precisa de extração dentro de um único serviço Go. Subir um Manager, um Worker, MongoDB, RabbitMQ e object storage custa mais do que a funcionalidade vale. **O que muda.** Seu serviço importa o módulo do Engine e o chama no próprio processo. O Engine não tem dependências de terceiros, então o import não acrescenta superfície operacional. Sem nenhum destino de resultado configurado, o Engine roda em modo direct e devolve as linhas inline como JSON indentado, com um digest SHA-256 sobre os bytes exatos. Essa saída é determinística. Uma entrada idêntica produz um JSON byte a byte idêntico e o mesmo digest, seja qual for a ordem em que os passos paralelos por fonte de dados terminaram. Você pode persistir esses bytes e assiná-los por conta própria. ## Atenda muitos tenants a partir de uma implantação *** **O problema.** Você roda um Fetcher para muitos clientes. Cada cliente registra os próprios hosts de banco de dados. Um cliente nunca pode ler as linhas de outro, e nenhum cliente pode apontar uma conexão para a sua rede interna. **O que muda.** O modo multi-tenant dá a cada tenant o próprio banco de metadados, resolvido a partir das claims do JWT na requisição. O acesso falha de forma fechada: uma requisição que carrega um ID de tenant sem banco de tenant retorna um erro em vez de ler o banco compartilhado. A mesma chave liga a validação de host. O Fetcher rejeita um host fornecido pelo tenant que resolva para um endereço privado, de loopback ou de metadados de nuvem. Ele checa um literal de IP no momento em que interpreta a requisição, e checa o hostname de novo na fábrica de fontes de dados. Fontes de dados internas configuradas pelo operador seguem isentas. ## Próximos passos *** Rode uma primeira extração sem infraestrutura, ou com a stack Docker completa. Conexões, descoberta de esquema, jobs de extração, filtros e resultados.