Trade‐offs y Riesgos - SebaUSM/GRUPO02-2025-PROYINF GitHub Wiki

En esta sección se presentan los principales trade-offs y riesgos identificados a partir de los concerns tratados.

Availability: Notificaciones de actualizaciones

Trade-offs

  • Disponibilidad vs. Complejidad del sistema
    Implementar mecanismos como colas persistentes, lógica de reintento, balanceo de carga y control de idempotencia mejora la disponibilidad, pero añade complejidad arquitectónica, tanto en su técnica como operatividad.

  • Entrega garantizada vs. Latencia
    Asegurar la entrega de todas las notificaciones, incluso en caso de fallos, requiere confirmaciones (ACKs), almacenamiento temporal y reintentos, lo que puede aumentar la latencia promedio de entrega.

  • Observabilidad vs. Rendimiento
    Integrar herramientas como Prometheus o Elastic Stack para monitorear el estado de entrega permite detectar fallos, pero puede generar sobrecarga si el volumen de eventos es alto y no se optimiza el logging y sus métricas correspondientes.

  • Alta disponibilidad vs. Costos de infraestructura
    Ejecutar servicios como RabbitMQ en clúster o balanceo de carga en WebSocket requiere de más recursos, lo cual aumenta los costos operacionales y puede demandar personal adicional para su mantenimiento.


Riesgos

  • Riesgo 1: Pérdida de mensajes si el destinatario está desconectado y no existen colas persistentes ni lógica de reintento implementada correctamente.

  • Riesgo 2: Duplicación de notificaciones en escenarios con múltiples reintentos sin mecanismos de idempotencia, lo que puede generar errores funcionales en el receptor.

  • Riesgo 3: Cuellos de botella causados por colas saturadas, errores en la configuración de reintentos o caídas de nodos de mensajería.

  • Riesgo 4: Dependencia excesiva en sistemas de observabilidad (como Prometheus o Kibana) que, si no están bien configurados o replicados, podrían dejar sin trazabilidad al sistema en momentos críticos.

  • Riesgo 5: Entregas fuera de orden o inconsistentes si el balanceo de carga o la persistencia de sesión no están bien manejadas en WebSocket o mensajería distribuida.


Security: Sistema de encriptación de contraseñas

Trade-offs

  • Seguridad vs. Rendimiento
    Algoritmos de hashing robustos como bcrypt, scrypt o Argon2 aumentan significativamente la seguridad, pero requieren mayor tiempo y recursos de CPU en comparación con algoritmos más simples.

  • Seguridad vs. Experiencia del usuario
    Forzar HTTPS, redireccionamientos y validaciones estrictas puede introducir una pequeña latencia adicional y complejidad para usuarios con configuraciones antiguas o dispositivos no actualizados.

  • Modularidad de autenticación vs. Complejidad arquitectónica
    Separar el módulo de autenticación del resto del sistema mejora la mantenibilidad y el aislamiento de fallos, pero implica más componentes que coordinar y asegurar correctamente.

  • Autenticación vs. Privacidad y almacenamiento
    Registrar intentos fallidos de autenticación es esencial para detectar ataques, pero debe hacerse con cuidado para no almacenar datos sensibles ni violar principios de minimización de datos o privacidad.


Riesgos

  • Riesgo 1: Almacenamiento inseguro de contraseñas si no se aplica un algoritmo de hashing actualizado y con salting, exponiendo al sistema a ataques de fuerza bruta u obtención de hashes.

  • Riesgo 2: Interceptación de credenciales si no se usa HTTPS de forma obligatoria en todas las rutas, incluyendo APIs y formularios.

  • Riesgo 3: Ataques de fuerza bruta o repetidos sin detección si no se implementa un módulo de auditoría con registros de intentos fallidos y alertas.

  • Riesgo 4: Acoplamiento indebido del módulo de autenticación con otras partes del sistema, lo cual puede generar dependencias circulares o vulnerabilidades al escalar o actualizar.

  • Riesgo 5: Logs mal gestionados pueden almacenar datos sensibles o habilitar accesos indebidos si no se protegen adecuadamente.


Availability: Respaldo de datos y boletines

Trade-offs

  • Frecuencia de respaldos vs. Consumo de recursos
    Respaldos frecuentes aseguran mayor protección ante fallos, pero pueden generar alta carga en disco, CPU y red, especialmente en sistemas con grandes volúmenes de datos.

  • Seguridad de almacenamiento vs. Accesibilidad
    Almacenar los respaldos en ubicaciones cifradas y replicadas aumenta la seguridad, pero puede dificultar la recuperación rápida si no se configuran correctamente los accesos o si hay problemas de sincronización.

  • Automatización vs. Control manual
    Automatizar completamente el respaldo reduce el riesgo de error humano, pero puede ocultar fallos si no se implementa monitoreo y validación de los procesos de backup.

  • Pruebas de restauración vs. Disponibilidad en tiempo real
    Ejecutar pruebas de recuperación de datos es esencial para validar los respaldos, pero estas pruebas pueden requerir entornos adicionales o incluso causar interrupciones si se ejecutan en producción.


Riesgos

  • Riesgo 1: Pérdida irreversible de información si el sistema de respaldos falla y no existen validaciones ni redundancia.

  • Riesgo 2: Fallas en la recuperación de datos si los respaldos no son consistentes, están incompletos o se encuentran corruptos al momento de usarse.

  • Riesgo 3: Brechas de seguridad si los respaldos no están cifrados o se almacenan en ubicaciones no seguras o accesibles por terceros no autorizados.

  • Riesgo 4: Retrasos en la restauración que afectan la disponibilidad del sistema si no existen procedimientos documentados o pruebas previas de recuperación.

  • Riesgo 5: Sobrecarga del sistema durante el proceso de respaldo, lo que puede generar lentitud o interrupciones si no se realiza en horarios planificados.