> ## 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 de Fetcher > Escenarios concretos para Fetcher: centralizar el acceso a bases de datos entre servicios, alimentar conciliación y reportes, publicar extractos verificables y embeber la extracción en tu propia aplicación. Cada escenario de abajo plantea primero el problema, y después qué cambia cuando Fetcher es dueño del camino de extracción. ## Deja de reconstruir el acceso a datos en cada servicio *** **El problema.** Lerian pasó por esto internamente. Cada equipo de producto construyó su propia lógica de acceso a datos contra las mismas bases de datos externas, y cada copia envejeció por separado. Fetcher existe para centralizar ese trabajo. El mismo patrón aparece en cualquier empresa que corre varios sistemas internos contra las mismas bases de datos operativas. Cada equipo escribe su propio pool de conexiones, su propio manejo de secretos y su propio constructor de consultas. Es el mismo trabajo, hecho cinco veces. **Qué cambia.** Un solo registro de conexión sirve a todos los consumidores. Fetcher cifra la contraseña una vez, prueba la conexión cuando lo pides y aplica los mismos diez operadores de filtro a los cinco tipos de base de datos. Un consumidor nuevo no registra drivers ni guarda credenciales. Llama a una API. Agregar un tipo de datasource pasa a ser trabajo de un equipo en lugar de trabajo de cinco. ## Alimenta conciliación y reportes desde bases de datos operativas *** **El problema.** La conciliación y la generación de reportes necesitan filas que viven fuera de la plataforma. Esas filas están en el PostgreSQL operativo de un banco, en el MySQL de un socio o en un almacén de clientes en MongoDB. El producto consumidor tiene que alcanzarlas sin volverse él mismo un cliente de base de datos. **Qué cambia.** El consumidor envía una selección de campos por datasource y por tabla. Fetcher valida esa selección contra el esquema vivo antes de ejecutar nada. Por eso una columna renombrada falla en el momento de planificar, no a mitad de la extracción. El Worker escribe el resultado en almacenamiento de objetos y publica `job.completed` o `job.failed`. El consumidor reacciona al evento. Fetcher también resuelve un conjunto fijo de datasources internos de Lerian a partir de variables de entorno, así que un reporte sobre datos de Midaz no necesita ninguna conexión registrada. ## Publica un extracto que un tercero puede verificar *** **El problema.** Envías un extracto de datos a un auditor, a un regulador o a un socio. Necesitan pruebas de que el archivo salió de tus sistemas y de que nadie lo editó en tránsito. **Qué cambia.** El Worker firma el JSON en texto plano con HMAC-SHA256 antes de cifrar el payload, y después guarda el resultado con cifrado AES-GCM en reposo. Quien lo recibe deriva la clave externa de verificación desde tu clave maestra con el comando `make derive-key`, y comprueba la firma de forma independiente. Esa clave derivada solo verifica firmas. No puede descifrar credenciales almacenadas, y no puede falsificar mensajes internos entre el Manager y el Worker. ## Agrega extracción a un servicio que ya operas *** **El problema.** Necesitas extracción dentro de un solo servicio Go. Levantar un Manager, un Worker, MongoDB, RabbitMQ y almacenamiento de objetos cuesta más que la funcionalidad. **Qué cambia.** Tu servicio importa el módulo del Engine y lo llama en proceso. El Engine no tiene dependencias de terceros, así que la importación no agrega superficie operativa. Sin ningún sink de resultados conectado, el Engine corre en modo directo y devuelve las filas en línea como JSON indentado, con un digest SHA-256 sobre los bytes exactos. Esa salida es determinista. La misma entrada produce un JSON idéntico byte a byte y el mismo digest, sin importar en qué orden terminaron los pasos paralelos por datasource. Puedes persistir esos bytes y firmarlos tú mismo. ## Sirve a muchos tenants desde un solo despliegue *** **El problema.** Corres un solo Fetcher para muchos clientes. Cada cliente registra sus propios hosts de base de datos. Un cliente nunca debe leer las filas de otro, y ningún cliente puede apuntar una conexión a tu red interna. **Qué cambia.** El modo multi-tenant da a cada tenant su propia base de datos de metadatos, resuelta a partir de los claims del JWT de la petición. El acceso falla cerrado: una petición que lleva un ID de tenant sin base de datos de tenant devuelve un error en lugar de leer la base de datos compartida. El mismo interruptor activa la validación de host. Fetcher rechaza un host provisto por el tenant que resuelve a una dirección privada, de loopback o de metadatos de nube. Revisa una dirección IP literal al parsear la petición, y de nuevo el nombre de host en la fábrica de datasources. Los datasources internos configurados por el operador quedan exentos. ## Próximos pasos *** Corre una primera extracción sin infraestructura, o con el stack completo de Docker. Conexiones, descubrimiento de esquema, jobs de extracción, filtros y resultados.