|
|
@@ -51,8 +51,18 @@ style: |
|
|
|
|
|
|
|
|
|
.box.warning {
|
|
|
- border-color: #f97316;
|
|
|
- background-color: #ffedd5;
|
|
|
+ border-color: #ffeeba;
|
|
|
+ background-color: #fff3cd;
|
|
|
+ }
|
|
|
+
|
|
|
+ .box.danger {
|
|
|
+ border-color: #f5c6cb;
|
|
|
+ background-color: #f8d7da;
|
|
|
+ }
|
|
|
+
|
|
|
+ .box.success {
|
|
|
+ border-color: #c3e6cb;
|
|
|
+ background-color: #d4edda;
|
|
|
}
|
|
|
|
|
|
/* Alineación */
|
|
|
@@ -94,8 +104,438 @@ style: |
|
|
|
|
|
|
---
|
|
|
|
|
|
+## ¿Qué es una arquitectura políglota?
|
|
|
+
|
|
|
+- Uso de **múltiples tecnologías de almacenamiento** en un mismo sistema
|
|
|
+- Cada tecnología se utiliza según **sus fortalezas**
|
|
|
+- No existe una única base de datos que resuelva todos los problemas
|
|
|
+<br>
|
|
|
+<div class="box w-80 center">
|
|
|
+ <strong>Hay que usar la tecnología adecuada para cada situación</strong>
|
|
|
+</div>
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+### Relacionales (SQL)
|
|
|
+<div class="box-compact">
|
|
|
+
|
|
|
+| Tipo | Características principales | Casos de uso | Ejemplos |
|
|
|
+|-------------------------|--------------------------------------------------------------|--------------------------------------|--------------------------|
|
|
|
+| Relacional clásico | ACID, modelo tabular, integridad referencial | Aplicaciones empresariales, CRUD | PostgreSQL, MySQL |
|
|
|
+| OLTP | Optimizado para muchas transacciones pequeñas | Sistemas operacionales (apps, APIs) | PostgreSQL, Oracle |
|
|
|
+| OLAP / Data Warehouse| Optimizado para consultas analíticas complejas | BI, reporting, análisis de datos | Snowflake, Redshift |
|
|
|
+| HTAP (híbrido) | Mezcla OLTP + OLAP en tiempo real | Sistemas con analítica en vivo | TiDB, Azure SQL HTAP |
|
|
|
+| Distribuido | Escalado horizontal, replicación, particionado | Sistemas globales y escalables | CockroachDB, YugabyteDB |
|
|
|
+
|
|
|
+</div>
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+### No Relacionales (NoSQL)
|
|
|
+
|
|
|
+<div class="box-compact">
|
|
|
+
|
|
|
+| Tipo | Características principales | Casos de uso | Ejemplos |
|
|
|
+|--------------------|-----------------------------------------------------|---------------------------------------|---------------------|
|
|
|
+| Documentales | Datos JSON/BSON, esquema flexible | APIs, datos semiestructurados | MongoDB, CouchDB |
|
|
|
+| Clave-Valor | Acceso ultrarrápido por clave | Cache, sesiones, estado temporal | Redis, DynamoDB |
|
|
|
+| Grafos | Relaciones complejas entre nodos | Redes sociales, recomendaciones | Neo4j |
|
|
|
+| Columnar (Wide) | Columnas distribuidas, gran escalabilidad | Big Data, logs, eventos masivos | Cassandra, HBase |
|
|
|
+| Búsqueda | Indexación y búsqueda full‑text | Buscadores, analítica textual | Elasticsearch |
|
|
|
+| Series temporales| Optimizadas para datos con timestamp | IoT, métricas, monitoring | InfluxDB, Timescale |
|
|
|
+| Multi‑modelo | Soportan varios modelos en un mismo motor | Sistemas híbridos complejos | ArangoDB, Cosmos DB |
|
|
|
+
|
|
|
+</div>
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+
|
|
|
+#### No hay una única solución óptima
|
|
|
+Cada tipo resuelve un problema distinto
|
|
|
+<br>
|
|
|
+<div class="box w-80 center">
|
|
|
+ <strong>Por eso las arquitecturas modernas son **políglotas**</strong>
|
|
|
+</div>
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+<div class="box warning">
|
|
|
+
|
|
|
+#### Complejidad
|
|
|
+- Uso de múltiples tecnologías == mayor complejidad global
|
|
|
+- Diferentes modelos de datos y APIs
|
|
|
+- Necesidad de orquestar varios sistemas
|
|
|
+
|
|
|
+</div>
|
|
|
+<br>
|
|
|
+<div class="box danger">
|
|
|
+
|
|
|
+#### Puntos de fallo
|
|
|
+- Cada tecnología añade:
|
|
|
+ - configuración propia
|
|
|
+ - características específicas de despliegue
|
|
|
+ - monitorización
|
|
|
+
|
|
|
+</div>
|
|
|
+<br>
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## Problemas más comunes
|
|
|
+
|
|
|
+### Consistencia de datos
|
|
|
+
|
|
|
+- No hay transacciones distribuidas sencillas
|
|
|
+- Posibles inconsistencias:
|
|
|
+ - estado actualizado en un sistema pero no persistido en otro
|
|
|
+ - fallos en mitad del proceso
|
|
|
+
|
|
|
+<br>
|
|
|
+
|
|
|
+**Necesario diseñar tolerancia a fallos**
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## Sincronización entre sistemas
|
|
|
+
|
|
|
+- ¿Cuándo mover los datos?
|
|
|
+ - en tiempo real
|
|
|
+ - mediante eventos
|
|
|
+ - mediante schedulers
|
|
|
+
|
|
|
+<br>
|
|
|
+
|
|
|
+**El diseño del flujo de datos es crítico**
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+### Transformación de datos
|
|
|
+
|
|
|
+- Cada sistema tiene su propio modelo:
|
|
|
+ - entidades (Java)
|
|
|
+ - DTOs
|
|
|
+ - documentos (Mongo)
|
|
|
+ - Key/Value (Redis)
|
|
|
+ - ...
|
|
|
+
|
|
|
+### Dificultad de debugging
|
|
|
+
|
|
|
+- Errores distribuidos entre servicios
|
|
|
+- Fallos difíciles de rastrear:
|
|
|
+ - llamadas remotas
|
|
|
+ - errores de serialización
|
|
|
+ - inconsistencias de datos
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## Conclusión
|
|
|
+
|
|
|
+<div class="box">
|
|
|
+
|
|
|
+ **Mayor flexibilidad implica mayor responsabilidad**
|
|
|
+
|
|
|
+</div>
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+
|
|
|
+## Caso práctico: Plataforma de Subastas
|
|
|
+
|
|
|
+### Problema
|
|
|
+
|
|
|
+Diseñar un sistema capaz de:
|
|
|
+
|
|
|
+- Gestionar subastas en tiempo real
|
|
|
+- Registrar pujas concurrentes
|
|
|
+- Mantener un histórico completo
|
|
|
+- Escalar correctamente ante múltiples usuarios
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+### Enfoque arquitectónico
|
|
|
+
|
|
|
+ Uso de una arquitectura **políglota**
|
|
|
+
|
|
|
+- Diferentes tecnologías para distintos problemas
|
|
|
+- Separación entre:
|
|
|
+ - estado en vivo
|
|
|
+ - persistencia histórica
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+### Objetivo
|
|
|
+
|
|
|
+Construir un sistema:
|
|
|
+
|
|
|
+- escalable
|
|
|
+- modular
|
|
|
+- alineado con prácticas reales de arquitectura moderna
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+### Tecnologías
|
|
|
+
|
|
|
+- BD relacion -> productos, categorías, usuarios... (**integridad**)
|
|
|
+- Redis -> estado activo de las subastas (**velocidad**)
|
|
|
+- MongoDB -> almacenamiento histórico (**flexibilidad**)
|
|
|
+- APIs REST -> integración entre servicios (**desacoplamiento**)
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## MongoDB (Base de datos documental)
|
|
|
+
|
|
|
+### Características principales
|
|
|
+
|
|
|
+- Modelo basado en documentos (JSON / BSON)
|
|
|
+- Esquema flexible (no fijo)
|
|
|
+- Fácil evolución del modelo de datos
|
|
|
+- Soporte natural para estructuras anidadas
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+### Casos de uso
|
|
|
+
|
|
|
+- Datos semiestructurados
|
|
|
+- Históricos y auditoría
|
|
|
+- Sistemas donde el modelo evoluciona
|
|
|
+- APIs modernas (JSON-centric)
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+<div class="box success">
|
|
|
+
|
|
|
+### Ventajas
|
|
|
+
|
|
|
+- Flexibilidad de diseño
|
|
|
+- Alta productividad en desarrollo
|
|
|
+- Modelo cercano al dominio de negocio
|
|
|
+- Escalabilidad horizontal
|
|
|
+
|
|
|
+</div>
|
|
|
+<br>
|
|
|
+<div class="box danger">
|
|
|
+
|
|
|
+### Desventajas
|
|
|
+
|
|
|
+- Menor control de integridad frente a SQL
|
|
|
+- Redundancia de datos
|
|
|
+- No ideal para transacciones complejas
|
|
|
+
|
|
|
+</div>
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## Redis (Clave-Valor en memoria)
|
|
|
+
|
|
|
+### Características principales
|
|
|
+
|
|
|
+- Base de datos en memoria
|
|
|
+- Acceso extremadamente rápido (ms)
|
|
|
+- Modelo clave-valor
|
|
|
+- Soporte de TTL (expiración automática)
|
|
|
+- Estructuras avanzadas (listas, sets, etc.)
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## Casos de uso
|
|
|
+
|
|
|
+- Cache
|
|
|
+- Estado temporal
|
|
|
+- Sesiones
|
|
|
+- Sistemas en tiempo real
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+<div class="box success">
|
|
|
+
|
|
|
+### Ventajas
|
|
|
+
|
|
|
+- Altísimo rendimiento
|
|
|
+- Simplicidad de uso
|
|
|
+- Ideal para datos efímeros
|
|
|
+- TTL nativo
|
|
|
+
|
|
|
+</div>
|
|
|
+<br>
|
|
|
+<div class="box danger">
|
|
|
+
|
|
|
+### Desventajas
|
|
|
+
|
|
|
+- Persistencia limitada (según configuración)
|
|
|
+- No pensado como almacenamiento principal
|
|
|
+- Consumo de memoria
|
|
|
+
|
|
|
+</div>
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+
|
|
|
+## Resolviendo los desafíos
|
|
|
+
|
|
|
+
|
|
|
+No intentar evitar la complejidad, hay que hacerla explícita y controlarla
|
|
|
+
|
|
|
+- Separación clara de responsabilidades
|
|
|
+- Flujo de datos bien definido
|
|
|
+- Uso de cada tecnología para lo que mejor sabe hacer
|
|
|
+
|
|
|
+<div class="box">
|
|
|
+
|
|
|
+**Diseño orientado a evitar acoplamientos innecesarios**
|
|
|
+
|
|
|
+</div>
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+### Separación de responsabilidades
|
|
|
+
|
|
|
+- **Relacional** -> garantiza integridad
|
|
|
+- **Redis** -> estado en tiempo real
|
|
|
+- **MongoDB** -> persistencia histórica
|
|
|
+- **API** -> lógica de negocio
|
|
|
+
|
|
|
+### Beneficios
|
|
|
+
|
|
|
+- Cada componente hace una sola cosa
|
|
|
+- Menor complejidad interna por módulo
|
|
|
+- Sistema más mantenible
|
|
|
+
|
|
|
+<div class="box">
|
|
|
+
|
|
|
+**Evitamos mezclar estado temporal con persistencia**
|
|
|
+
|
|
|
+</div>
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## Control del ciclo de vida de las subastas
|
|
|
+
|
|
|
+<div class="box danger">
|
|
|
+
|
|
|
+#### Problema
|
|
|
+
|
|
|
+- Redis elimina datos al expirar
|
|
|
+- No podemos recuperar el estado después
|
|
|
+
|
|
|
+</div>
|
|
|
+<br>
|
|
|
+<div class="box success">
|
|
|
+
|
|
|
+#### Solución
|
|
|
+
|
|
|
+Eliminamos dependencia de eventos internos
|
|
|
+
|
|
|
+- Definimos el tiempo de vida de nuestros eventos
|
|
|
+- Introducimos un **scheduler** para gestionar la persistencia
|
|
|
+
|
|
|
+</div>
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+### Flujo
|
|
|
+
|
|
|
+1. Subasta activa en Redis
|
|
|
+2. Scheduler detecta expiración
|
|
|
+3. Persistencia en Mongo
|
|
|
+4. Eliminación controlada
|
|
|
+
|
|
|
+<br>
|
|
|
+<div class="box">
|
|
|
+
|
|
|
+**Control explícito del sistema**
|
|
|
+
|
|
|
+</div>
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+### Transformación y enriquecimiento
|
|
|
+
|
|
|
+<div class="box danger">
|
|
|
+
|
|
|
+#### Problema
|
|
|
+
|
|
|
+- Datos distribuidos en varios servicios
|
|
|
+- Representaciones incompletas
|
|
|
+
|
|
|
+</div>
|
|
|
+<br>
|
|
|
+<div class="box success">
|
|
|
+
|
|
|
+#### Solución
|
|
|
+
|
|
|
+- Feign obtiene entidades base
|
|
|
+- Resolución de relaciones
|
|
|
+- Construcción de DTO completo (enriquecidos)
|
|
|
+
|
|
|
+</div>
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+### Reactividad
|
|
|
+
|
|
|
+**NO es necesaria, pero si conveniente**
|
|
|
+
|
|
|
+- Sistema con múltiples llamadas remotas
|
|
|
+- Necesidad de gestionar concurrencia de forma eficiente
|
|
|
+- Evitar bloqueos y mejorar rendimiento
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+<div class="box success">
|
|
|
+
|
|
|
+#### Ventajas
|
|
|
+
|
|
|
+- Mejor uso de recursos
|
|
|
+- Alta capacidad de concurrencia
|
|
|
+- Código expresivo para flujos complejos
|
|
|
+
|
|
|
+</div>
|
|
|
+<br>
|
|
|
+<div class="box danger">
|
|
|
+
|
|
|
+#### Inconvenientes
|
|
|
+
|
|
|
+- Mayor complejidad conceptual
|
|
|
+- Manejo cuidadoso de errores
|
|
|
+- Debugging más difícil
|
|
|
+
|
|
|
+</div>
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+#### ¿En qué casos merece la pena?
|
|
|
+
|
|
|
+- Obtener datos
|
|
|
+- Enriquecer información (usuario, categoría, etc.)
|
|
|
+- Persistir resultado final
|
|
|
+
|
|
|
+**Todo en un pipeline no bloqueante**
|
|
|
+
|
|
|
+<div class="box">
|
|
|
+
|
|
|
+La reactividad es una forma distinta de modelar el flujo del sistema
|
|
|
+
|
|
|
+</div>
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+
|
|
|
+### Resultado
|
|
|
+
|
|
|
+- Independencia de servicios externos
|
|
|
+- Gestión de llamadas no bloqueante
|
|
|
+- Datos listos para persistencia
|
|
|
+ - Necesidad de integridad -> sistema relacional
|
|
|
+ - Ciclo de vida -> Redis
|
|
|
+ - Snapshot completo redundado -> Mongo
|
|
|
+
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
<img src="img/diagrama_componentes.png" width="90%"/>
|
|
|
|
|
|
---
|
|
|
|
|
|
-<img src="img/diagrama_componentes.png" width="90%"/>
|
|
|
+<img src="img/diagrama_componentes.png" width="90%"/>
|
|
|
+
|
|
|
+---
|