FASE 6 – DISEÑO DE DATOS MULTIMODELO +
PERFORMANCE + OPTIMIZACIÓN ENTERPRISE
Guía Brutal Nivel Grandes Ligas
Aplicable a CORE-PLATFORM | IAM-SERVICE | AI-SERVICE
INTRODUCCIÓN ESTRUCTURAL A LA FASE 6
En arquitectura enterprise real, el diseño de datos no es una consecuencia del código. Es
una decisión estratégica que impacta rendimiento, escalabilidad, costos, seguridad y
capacidad analítica.
En ecosistemas como Solveria, donde coexistirán múltiples verticales, múltiples tenants
y componentes de inteligencia artificial, el diseño debe ser multimodelo:
PostgreSQL (modelo relacional fuerte)
MongoDB (modelo documental flexible)
Vector Database (embeddings para IA)
La pregunta no es “qué base usamos”, sino:
¿Qué tipo de consistencia requiere cada agregado?
¿Qué tipo de consultas se ejecutarán?
¿Qué volumen se proyecta?
¿Qué patrones de acceso dominan?
1. MODELO CONCEPTUAL – REPRESENTACIÓN DEL
DOMINIO
El modelo conceptual no depende de tecnología.
Debe incluir: - Entidades principales. - Relaciones. - Cardinalidades. - Límites de
agregados.
Ejemplo EduPredict AI:
Entidad: Estudiante Entidad: Curso Entidad: Nota Entidad: Universidad (Tenant)
Relaciones: Universidad 1..* Estudiante Estudiante 1..* Nota Curso 1..* Nota
El modelo conceptual debe alinearse con la Fase 2.
Error común: Diseñar tablas antes de diseñar agregados.
2. MODELO LÓGICO – DECISIÓN TECNOLÓGICA
Aquí se decide qué vive en qué motor.
Criterios para PostgreSQL
Consistencia fuerte.
Relaciones complejas.
Integridad referencial.
Transacciones críticas.
Ejemplo: Estudiante, Notas, Universidad.
Criterios para MongoDB
Datos flexibles.
Estructuras variables.
Logs o historiales extensos.
Documentos agregados.
Ejemplo: Historial de interacciones del estudiante.
Criterios para Vector DB
Embeddings.
Búsqueda semántica.
Recuperación contextual (RAG).
Ejemplo: Embeddings de comportamiento académico.
Deben justificar cada decisión.
3. MODELO FÍSICO – OPTIMIZACIÓN REAL
El modelo físico define:
Tipos de datos.
Índices.
Constraints.
Estrategias de particionamiento.
Ejemplo PostgreSQL:
Tabla estudiante: - id UUID - tenant_id UUID - promedio NUMERIC - version INT
(@Version)
Índices: - (tenant_id) - (tenant_id, estado_academico)
Justificación: Consultas frecuentes por tenant y estado.
4. INDEXACIÓN ESTRATÉGICA
Un índice mal diseñado puede destruir performance.
Deben documentar:
Consultas más frecuentes.
Campos filtrados.
Campos ordenados.
Ejemplo: Consulta frecuente: estudiantes en riesgo alto por universidad.
Índice recomendado: (tenant_id, nivel_riesgo)
No indexar todo. Indexar estratégicamente.
5. PARTICIONAMIENTO Y ESCALABILIDAD
En sistemas multi-tenant grandes:
Estrategias: - Partición por tenant. - Partición por fecha. - Sharding.
Ejemplo: Eventos académicos particionados por año académico.
Deben proyectar crecimiento a 3–5 años.
6. EVENT STORE Y DATOS HISTÓRICOS
Si el sistema usa arquitectura orientada a eventos:
Deben definir:
Tabla de eventos.
Índices por tenant.
Estrategia de archivado.
Ejemplo: Tabla domain_event con tenant_id, event_type, timestamp.
7. DISEÑO PARA IA – EMBEDDINGS Y VECTOR
SEARCH
Para AI-SERVICE deben documentar:
Qué datos se vectorizan.
Frecuencia de actualización.
Tamaño estimado del embedding.
Ejemplo: Embedding por estudiante basado en historial académico.
Decisión: PGVector si ya se usa PostgreSQL. Mongo Atlas Vector Search si se prioriza
documental.
Deben justificar elección.
8. PERFORMANCE-DRIVEN DESIGN
Deben listar:
Top 5 consultas críticas.
Tiempo máximo aceptable.
Estrategia de caching.
Ejemplo: Consulta dashboard rector → máximo 2 segundos.
Estrategia: Materialized views o cache Redis.
9. CONSISTENCIA Y REPLICACIÓN
En entornos enterprise:
Replica para lectura.
Nodo primario para escritura.
Deben documentar:
Qué consultas van a réplica.
Qué operaciones requieren primario.
10. SEGURIDAD EN CAPA DE DATOS
Deben incluir:
Encriptación en reposo.
Encriptación en tránsito.
Separación de credenciales por servicio.
Multi-tenant exige evitar acceso transversal.
11. ANTI-PATRONES EN DISEÑO DE DATOS
Mezclar datos de tenants sin filtro.
No incluir tenant_id en índices.
Diseñar sin proyección de crecimiento.
No versionar modelos de IA.
Cada anti-patrón debe explicarse con consecuencias.
CHECKLIST ENTERPRISE FASE 6
✓ Modelo conceptual alineado con dominio. ✓ Decisión justificada SQL vs NoSQL. ✓
Índices definidos según consultas reales. ✓ Estrategia de particionamiento
documentada. ✓ Diseño para IA definido. ✓ Estrategia de performance clara. ✓
Seguridad en capa de datos considerada. ✓ Proyección de crecimiento a largo plazo.
CIERRE ESTRUCTURAL
Si esta fase se ejecuta con rigor:
El sistema será performante.
Escalará sin rediseño radical.
Soportará IA con eficiencia.
Mantendrá aislamiento multi-tenant.
Si se ejecuta mal:
Habrá cuellos de botella.
Escalabilidad limitada.
Costos elevados.
Riesgo de fuga de datos.
En arquitectura de grandes ligas, el diseño de datos no es una tarea técnica secundaria.
Es una decisión estratégica que define la viabilidad del ecosistema completo.