Stakeholders	Concern (Preocupación / Necesidad)	Atributo de Calidad Impactado
Alumno	Recibir corrección de ensayos con feedback en < 3 segundos de forma consistente, sin tiempos muertos o errores.	Rendimiento (Performance), Disponibilidad (Availability)
Profesor	Mantener la integridad del banco de preguntas durante creación/edición, evitando estados inconsistentes o datos corruptos.	Integridad de Datos (Data Integrity), Usabilidad (Usability)
Institución Educativa (Cliente)	Reducir costos de mantenimiento y facilitar la evolución del sistema tras la migración arquitectónica, con despliegues confiables.	Modificabilidad (Modifiability), Desplegabilidad (Deployability)

---

La experiencia del alumno durante la corrección es crítica. Demoras o errores generan frustración inmediata y desconfianza en la herramienta educativa.

• Rendimiento: Latencia baja (< 3s) en el proceso de corrección.
• Disponibilidad: El sistema debe estar siempre accesible

1. Contenedores Independientes: La separación en contenedores para frontend, backend y BD permite que cada uno escale según sus necesidades. El backend (donde ocurre la corrección) puede replicarse sin afectar las otras capas.

2. Bases de Datos Especializadas: Tener Bases de Datos separadas para contenido (preguntas/ensayos) y usuarios reduce contención y mejora el rendimiento de las consultas específicas de corrección.

3. Aislamiento de Fallos: Si el frontend falla, el backend y la lógica de corrección siguen operativos (y viceversa), mejorando la disponibilidad general.

La calidad del proceso educativo depende de la integridad del banco de preguntas. Datos inconsistentes invalidarían las correcciones automáticas

• Integridad de Datos: Garantizar coherencia transaccional en las operaciones.
• Usabilidad: Flujos de trabajo robustos para creación/edición.

1. Validación en Capa de Servicio: El backend (como monolito lógico) centraliza todas las reglas de negocio, asegurando validaciones consistentes independientemente del frontend.

2. Transacciones por Base de Datos: Cada base de datos (usuarios y contenido) maneja sus propias transacciones ACID, garantizando consistencia dentro de su dominio.

3. API Bien Definida: El contrato claro entre frontend y backend previna envío de datos inválidos.

El cliente necesita que la nueva arquitectura justifique la migración siendo más fácil y barata de mantener que el monolitospaghetti anterior.

• Modificabilidad: Poder hacer cambios con impacto localizado.
• Desplegabilidad: Desplegar componentes de forma independiente.

1. Separación de Responsabilidades: Cada contenedor tiene una responsabilidad única y bien definida, lo que reduce la complejidad cognitiva para los desarrolladores.
2. Dockerización: Los Dockerfiles estandarizados permiten builds y despliegues consistentes en todos los entornos.
3. Frontend Desacoplado: Puede evolucionar independientemente del backend, permitiendo mejoras en la UX sin afectar la lógica de negocio.

---

Decisión de Arquitectura	Beneficio Principal	Trade-off Aceptado	Riesgo Potencial	Mitigación Propuesta
Monolito por Capas con Contenedores (vs. monolitospaghetti original)	Mantenibilidad radicalmente mejorada, despliegues más confiables, y posibilidad de escalado selectivo.	Complejidad operativa: ahora hay 3+ servicios para monitorear, y la red se convierte en un punto de falla potencial.	Latencia añadida por comunicación entre contenedores, y debugging distribuido más complejo que en un monolito único.	Usar Docker Compose para desarrollo; implementar logging centralizado y health checks; diseñar APIs con timeouts adecuados.
Múltiples Bases de Datos (Usuarios vs Contenido)	Mejor rendimiento al especializar cada BD, y contención reducida entre módulos.	Imposibilidad de transacciones ACID cruzadas entre bases de datos. Consistencia eventual en operaciones que involucren ambos dominios.	Datos inconsistentes si una operación falla parcialmente (ej: se crea usuario pero no su curso asociado).	Patrón Saga para operaciones distribuidas; reconciliación periódica de datos; validaciones de consistencia en la lógica de negocio.
Frontend Completamente Desacoplado	Equipos pueden trabajar independientemente; mejor capacidad de prueba; actualizaciones de UI sin tocar backend.	Posible desalineación entre frontend y backend si los contratos API no se mantienen rigurosamente.	Errores en producción por incompatibilidades de versión entre frontend y backend.	Definir contratos API con OpenAPI/Swagger; tests de integración automatizados; versionado semántico de APIs.