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

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.

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.

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.

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.

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.

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.