> ## 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.** Una conexión externa pertenece a un producto. Los consumidores de ese producto pueden reutilizarla; el `metadata.source` de un job debe coincidir con el producto de la conexión. 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.** Para datasources genéricos, el Worker valida las tablas y los campos seleccionados durante la planificación antes de consultar datos. Esa validación usa un snapshot de esquema con caché primero, por lo que un acierto de caché no es una comprobación contra el esquema vivo. La ruta de compatibilidad `plugin_crm` es separada. El Worker escribe los resultados del servicio independiente en almacenamiento de objetos y publica `job.completed` o `job.failed`; el consumidor reacciona al evento. En modo single-tenant, Fetcher carga datasources internos fijos desde variables de entorno `DATASOURCE_{NAME}_*`. En modo multi-tenant, los resuelve por tenant mediante Tenant Manager. En ambos modos son conexiones internas en memoria y no necesitan un registro de conexión en MongoDB. ## 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 resuelve recursos de metadatos desde el contexto de tenant que suministra el middleware de tenant. El acceso falla cerrado: una solicitud sin base de datos de tenant resuelta devuelve un error en lugar de leer una 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.