Arquitectura del lake

El lake es un esquema canónico versionado: los conectores escriben, la distribución lee. Nada consume del core directo.

El pipeline

flujo

core bursátil ──▶ EXTRACT ──▶ NORMALIZE ──▶ LAKE ──▶ SERVE
 (API / CDC /      lee lo       mapea al       guarda      API REST
  archivos)        que la       esquema        con         webhooks
                   superficie   canónico       historia    dashboards
                   permita      versionado     completa    Ally (IA)

La separación importa: el conector absorbe la complejidad de cada core una sola vez, y todos los consumidores ven siempre el mismo esquema. Si el core cambia su formato, se adapta el conector — tu integración no se entera.

Datasets canónicos

Parámetro	Tipo	Descripción
`lake.instrumentos`	dataset	Panel completo: bonos, acciones, CEDEARs, ONs, letras, FCIs.
`lake.cotizaciones`	dataset	Serie histórica de precio y volumen por instrumento.
`lake.comitentes`	dataset	Cuentas de cada ALyC, con titular e identificación fiscal.
`lake.saldos`	dataset	Disponible y bloqueado por moneda, por comitente.
`lake.tenencias`	dataset	Posiciones con cantidad y precio promedio.
`lake.movimientos`	dataset	Compras, ventas, depósitos, extracciones, rentas, dividendos.

Decisiones de diseño

Esquema versionado. Los cambios al esquema canónico se versionan como una API: nada se rompe sin un período de convivencia.

Aislamiento por cliente. El dato de cada ALyC es de esa ALyC: las keys con scope de cuentas quedan limitadas a su dueño, y la arquitectura soporta segregación física por cliente cuando el compliance lo exige.

Auditable por diseño. Cada request queda logueado (endpoint, key, latencia, status) y cada acción del backoffice deja rastro en BackofficeAction. El regulador argentino exige cada vez más trazabilidad — acá viene de fábrica.

La IA lee del lake, no al revés. Ally consume el mismo esquema canónico que la API. No hay un "modelo con acceso a la base": hay una capa de contexto curada y auditable.