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
Primeros pasos
Corre una primera extracción sin infraestructura, o con el stack completo de Docker.
Conceptos centrales
Conexiones, descubrimiento de esquema, jobs de extracción, filtros y resultados.