Justificación cambio de ASRs de Latencia por Disponibilidad

Durante la definición de los escenarios de calidad para el sistema, inicialmente se habían considerado 2 escenarios asociados al atributo de latencia junto con otros 2 escenarios de seguridad. Sin embargo, en el proceso de diseño y actualización de la arquitectura de esta semana, se identificaron dos aspectos críticos:

1. Conflicto entre latencia y seguridad:

   • En el análisis arquitectónico que realizamos se observó que al favorecer estrictamente el atributo de latencia, se debilitaban medidas de seguridad.

   • Ejemplo: mecanismos como autenticación multifactor (MFA), cifrado en tránsito y validaciones adicionales generan sobrecarga que afectan directamente los tiempos de respuesta.

   • Esto suponía un trade-off difícil de balancear, dado que la seguridad es innegociable por la naturaleza de los datos sensibles y las exigencias regulatorias del proyecto.

2. Sinergia entre disponibilidad y seguridad:

   • A diferencia de la latencia, el atributo de disponibilidad puede trabajarse de forma complementaria con la seguridad.

   • Decisiones arquitectónicas como el despliegue en la nube, uso de balanceadores, replicación de datos, redundancia de servicios y monitoreo continuo puede favorecer tanto la disponibilidad como el cumplimiento de los controles de seguridad.

   • Esto asegura que los escenarios de calidad seleccionados no entren en conflicto, sino que se refuercen mutuamente.

Conclusión

Por lo anterior, se decidió reemplazar los 2 escenarios de latencia por 2 escenarios de disponibilidad, priorizando ASRs que:

• Están directamente alineados con las restricciones de negocio del proyecto (99.95% de disponibilidad).

• Pueden coexistir de manera sinérgica con los escenarios de seguridad, sin generar conflictos de diseño.

• Representan atributos de calidad fundamentales para garantizar la confiabilidad, confianza del cliente y sostenibilidad de la solución en el tiempo.