Estilos Tacticas Patrones
- Manejo de recursos compartidos - múltiples copias de computación
- Manejo de recursos compartidos - múltiples copias de datos
- Acceso a los recursos - dar prioridad a los eventos
Razonamiento sobre las principales decisiones de arquitectura tomadas en este modelo
Para favorecer el atributo de latencia en el requisito de arquitectura de evaluación de la respuesta en menos de 300 milisegundos, cuando un candidato está resolviendo una prueba técnica, se toma la decisión de trabajar el estilo de arquitectura de N-niveles e implementar dos tácticas de manejo de recursos compartidos: múltiples copias de datos y múltiples copias de computación.
Para la táctica de múltiples copias de datos, se plantea manejar un servicio de cache para las preguntas de la prueba que está presentando el candidato, de esta manera el microservicio PruebasOrquestador podrá validar directamente si el candidato respondió correctamente la pregunta o no. Adicionalmente, mientras la prueba no haya finalizado, tendrá acceso a la siguiente pregunta desde la cache.
Con respecto a la táctica de múltiples copias de computación, para reducir el tiempo de espera se plantea instanciar múltiples pods de los microservicios Candidatos, Pruebas, Preguntas y PruebasOrquestador, a través de la respectiva configuración del orquestador de contenedores (EKS). Para obtener el rango de pods adecuados a configurar en Kubernetes, se planea experimentar con esta historia de arquitectura. En caso de no validar la hipótesis de diseño del experimento, se tiene como alternativa ajustar el diseño incluyendo la táctica de Acceso a los recursos - Dar prioridad a los eventos y otra posibilidad sería cambiar el servicio de Caché por DynamoDB.
- Detectar fallas - healthcheck
- Enmascarar fallas - identificar y retirar componente defectuoso
- Recuperación de fallos - reinicio de componente
Razonamiento sobre las principales decisiones de arquitectura tomadas en este modelo
Para favorecer el atributo de disponibilidad 7x24x365 para la historia de arquitectura de presentación pruebas de selección asignadas a los candidatos durante su proceso de selección, se toma la decisión de trabajar el estilo de arquitectura de microservicios y aprovechar las funcionalidades del orquestador de contenedores (EKS de AWS) para la detección de fallas, el retiro de componente(s) defectuoso(s) y el reinicio de componente(s).
- Mantener una alta cohesión
- Mantener un bajo acoplamiento
- Reducir el tamaño de los módulos - Dividir módulos.
Razonamiento sobre las principales decisiones de arquitectura tomadas en este modelo
Dentro del ciclo de vida del software es normal que el sistema deba presentar mejoras de manera continua con el fin de evolucionar y permitir agregar o modificar funcionalidades acordes con la dinámica del negocio. La facilidad de modificación es un atributo de calidad que interesa a los administradores del sistema, en especial para poder responder rápidamente a las solicitudes del cliente.
Por lo anterior, para favorecer el atributo de facilidad de modificación, el equipo propone diseñar componentes tipo microservicios y aplicar las tácticas de componentes de bajo tamaño, de única responsabilidad, que permitan generar cambios a futuro únicamente en los servicios requeridos. Adicionalmente, al ser componentes independientes, permite mantener un bajo acoplamiento y una alta cohesión.
- Manejo de recursos compartidos - múltiples copias de computación
- Manejo de recursos compartidos - múltiples copias de datos
Razonamiento sobre las principales decisiones de arquitectura tomadas en este modelo
Para este caso, teniendo en cuenta que se espera a nivel de requisito funcional que la aplicación sea capaz de procesar de manera concurrente desde 30 hasta 100 usuarios al tiempo , se propone en la arquitectura implementar para favorecer la escalabilidad el estilo de N-niveles y la táctica de manejo de recursos compartidos, en este caso con manejo de múltiples copias de computación y de datos, lo anterior para crecer de manera horizontal de forma tal que permita atender la demanda solicitada mediante el escalamiento de nuevos nodos dentro del clúster en el despliegue propuesto.
En este caso a nivel de despliegue se propone emplear los recursos de escalamiento que proporciona la nube AWS, así como la implementación de copias de datos para facilitar el acceso a los bancos de preguntas, que permitan atender la demanda en los tiempos esperados empleando servidores de caché para el almacenamiento de los resultados y cálculo de próximas preguntas a presentar de acuerdo al resultado evaluado de la respuesta anterior.
Razonamiento sobre las principales decisiones de arquitectura tomadas en este modelo
En modelo presenta el diagrama de clases de alto nivel, sin embargo, es de gran utilidad indicar que, debido a temas de costos, los microservicios implementarán sus entidades, para las operaciones de command (insert, update, delete), en una instancia RDS de AWS separadas por esquemas, y para las consultas, en una instancia de AuroraDB.
Adicionalmente, importante mencionar que, para favorecer la latencia, se decidió implementar la táctica de manejo de recursos compartidos - múltiples copias de datos, subiendo a caché las preguntas de una prueba en ejecución por parte de un candidato. Una vez terminada y calificada la prueba, la información es eliminada de la cache.
Patrón CQRS
Usando AWS AuroraDB para Queries y RDS para Commands.
Busca optimizar la velocidad de las consultas y las operaciones de modificación, favoreciendo atributos relacionados al desempeño.
Nos permite implementar y optimizar de manera independiente las responsabilidades de comandos y queries, una parte del equipo se puede hacer cargo del modelo de escritura mientras otros se dedican a la interfaz de usuario y al modelo de lectura.
