Proyectos

Sector: Financiero

Producción

Lakehouse financiero on-prem

Un lakehouse DuckLake self-hosted para una cooperativa financiera regulada.

Diagrama de arquitectura

Una cooperativa financiera regulada tenía toda su analítica atrapada en el core Oracle. Diseñé un lakehouse on-prem sobre DuckLake que la libera, automatiza los certificados de deuda y habilita el tablero regulatorio, con stack 100% open source self-hosted.

La protección de datos no fue un añadido posterior: fue uno de los focos de diseño desde el inicio, con la rigurosidad legal y contractual del sector (habeas data, minimización, confidencialidad). Su expresión técnica —anonimizar un core de ~740 tablas preservando la integridad referencial— fue la parte más difícil del proyecto.

Métricas clave

Filas en Silver (20,3M en el fact núcleo)
~40M Filas en Silver (20,3M en el fact núcleo)
Tablas anonimizadas con integridad referencial
~740 Tablas anonimizadas con integridad referencial
Stack OSS self-hosted
100% Stack OSS self-hosted
Bug crítico de producción detectado y corregido
1 Bug crítico de producción detectado y corregido

Stack

  • DuckLake
  • DuckDB
  • PostgreSQL
  • SeaweedFS
  • Parquet
  • Windmill
  • n8n

Decisiones y trade-offs

  1. Protección de datos como foco de diseño, no como parche

    La rigurosidad legal-contractual (habeas data, minimización, confidencialidad) guió la arquitectura desde el inicio. Se expresó en la anonimización de un core de ~740 tablas preservando la integridad referencial: lo más difícil, y un diferenciador real para un sector regulado.

  2. DuckLake (catálogo + Parquet + DuckDB)

    Apostar por DuckLake —vanguardia de 2025— dio un lakehouse abierto sobre catálogo PostgreSQL, Parquet en SeaweedFS y motor DuckDB, validado extremo a extremo contra el Oracle original. Sin dependencia de un DW propietario ni de la nube.

  3. El JOIN que emitía certificados inválidos

    Durante la validación aparecieron certificados de deuda inválidos por un JOIN roto en el proceso heredado. Detectado y corregido: un bug de producción con impacto legal, encontrado gracias a comparar el lakehouse contra la fuente.

  4. Rigor financiero de extremo a extremo

    Aritmética decimal (nunca float para dinero), provisiones por tramos y controles regulatorios (SARLAFT / PEP) modelados en las capas, no delegados al consumo.