El ELT —cargar primero el dato en crudo y transformarlo después, dentro del propio motor de destino— se ha vendido como una característica del cloud, pero es un patrón arquitectónico, no una función de Snowflake o BigQuery. Se puede hacer —y se hace— on-premise, sobre SQL Server, Oracle o PostgreSQL, y para muchas empresas con datos sensibles o restricciones de coste es una opción perfectamente válida.
Aquí explico qué es, por qué lo confundimos con la nube, cómo se implementa on-premise y cuándo conviene..

Airflow, Prefect, dbt, NiFi y Kafka son un ejemplo de stack de integración —el del modern data stack open-source, código primero— que este capítulo usa como hilo conductor para entender los cuatro planos de un pipeline: quién orquesta (Airflow, Prefect), quién transforma (dbt), quién mueve los datos (NiFi) y sobre qué viajan los eventos en tiempo real (Kafka).
No son "las mejores" herramientas ni la única vía válida. El mercado ofrece desde plataformas comerciales integradas —Informatica, Azure Data Factory, AWS Glue, Talend y el resto del TOP 10 de Dataprix— hasta decenas de alternativas open-source por cada capa.
La pregunta correcta no es "¿qué cinco herramientas elijo?", sino entender los planos, elegir un arquetipo coherente con tu equipo y tu caso, y no usar una herramienta excelente para el trabajo equivocado..

La integración de datos es la fontanería invisible sobre la que se sostiene toda la arquitectura: sin ella, el data lake del capítulo 8, los pipelines de los próximos capítulos y los dashboards de la Parte IV son cajas vacías. La decisión más importante no es qué herramienta comprar, sino cuándo mover los datos: en tiempo real, evento a evento, o agrupados en lotes a intervalos fijos.

Este capítulo desgrana las cuatro piezas fundamentales —eventos, mensajería, colas y Change Data Capture (CDC)— y ofrece criterios de consultoría para no caer en el error más caro de todos: aplicar streaming a problemas que el batch resolvía a una décima parte del coste, o forzar el batch donde el negocio exige inmediatez.

Una fintech es, en esencia, una empresa de datos que casualmente mueve dinero. Su plataforma tiene que conciliar lo que en otros sectores va por separado: latencia de milisegundos para autorizar pagos, consistencia transaccional estricta para que ningún saldo cuadre mal, analítica masiva para el antifraude y el scoring, y trazabilidad regulatoria perpetua para el supervisor.
En este caso práctico —que cierra la Parte II de la Guía— se diseña ese stack de principio a fin a través de una fintech europea, recorriendo las decisiones, los trade-offs y los errores evitados: del ledger inmutable a la idempotencia, del tiering de almacenamiento a la resiliencia por niveles de criticidad. Incluye un incidente real que demuestra por qué las decisiones que parecían sobreingeniería cara fueron justo las que salvaron la operación.

Cambiar el esquema de una base de datos viva es una de las operaciones más temidas de cualquier equipo de plataforma: un simple RENAME mal ejecutado puede tumbar un servicio que factura miles de transacciones por minuto. Pero la diferencia entre un equipo frágil y uno maduro no está en si migran, sino en cómo lo hacen. Este capítulo desgrana el trípode del cambio seguro en producción —patrón expand/contract, feature flags y compatibilidad hacia atrás— para convertir la migración de esquema en una operación rutinaria, reversible y sin downtime..

Este capítulo ofrece una hoja de ruta completa para diseñar, implementar y verificar la estrategia de resiliencia y disaster recovery de la capa de datos. No se trata solo de tener backups —que, por supuesto, son imprescindibles— sino de construir un sistema en el que cada componente conoce su RTO (Recovery Time Objective) y su RPO (Recovery Point Objective), donde los procedimientos de recuperación están documentados en runbooks operativos verificados, y donde las pruebas de DR se ejecutan con la misma disciplina con la que se ejecutan las pruebas de rendimiento o los pen tests de seguridad..

La observabilidad en la capa de datos es la disciplina que convierte el comportamiento interno de bases de datos, pipelines y motores de almacenamiento en información accionable para los equipos de ingeniería. A diferencia de la simple monitorización —que alerta cuando algo ya ha roto—, la observabilidad permite anticipar degradaciones, diagnosticar causas raíz y comprender el estado del sistema en tiempo real.
En este capítulo se analizan en profundidad las métricas esenciales por tipo de base de datos, los patrones de distributed tracing aplicados a la capa de datos, las estrategias de alerting que van más allá de los umbrales estáticos, las herramientas del ecosistema actual y los riesgos que pueden convertir un proyecto de observabilidad en un grave problema de señal-ruido..

Si hay una factura de infraestructura que crece de manera silenciosa hasta convertirse en un problema de comité de dirección, esa es la del almacenamiento en la nube. Según estimaciones de FinOps Foundation, entre el 25 % y el 35 % del gasto cloud de una organización media se destina a almacenar datos, y de ese volumen, cerca de un tercio corresponde a información a la que nadie ha accedido en los últimos seis meses. El escenario es tan habitual como preocupante: un data lake que comenzó como un repositorio prometedor se transforma en un data swamp donde conviven petabytes de logs sin catalogar, copias redundantes de backups y snapshots huérfanos que nadie se atreve a borrar porque «quizá alguien los necesite».

En la arquitectura de datos empresarial existe una paradoja que todo ingeniero descubre tarde o temprano: la base de datos más rápida es aquella a la que no necesitas preguntar. Las cachés y los aceleradores de datos constituyen probablemente la inversión con mayor retorno inmediato en cualquier plataforma de datos. Con una implementación correcta, es habitual ver reducciones del 70-95 % en latencia de lectura, caídas del 40-60 % en carga sobre bases de datos primarias, y una capacidad de absorción de picos de tráfico que convierte incidentes potenciales en meros incrementos logarítmicos en gráficas de monitorización..