Software Architecture
Atributos de calidad
Explica atributos de calidad como rendimiento, disponibilidad, resiliencia, seguridad, modificabilidad, testabilidad, observabilidad e interoperabilidad.
- Última actualización
- Actualizada
- Nivel
- Fundamentos
Software Architecture
Explica atributos de calidad como rendimiento, disponibilidad, resiliencia, seguridad, modificabilidad, testabilidad, observabilidad e interoperabilidad.
Los atributos de calidad describen cómo debe comportarse un sistema, no solo qué funciones ofrece. La arquitectura existe, en gran parte, para hacer posibles esas cualidades bajo condiciones reales de carga, cambio, fallo y ataque.
Dos sistemas pueden implementar exactamente las mismas funciones y, aun así, ser productos completamente distintos.
Ambos pueden permitir crear pedidos, consultar inventario y registrar pagos. Sin embargo, uno puede responder en 150 ms, recuperarse de fallos, impedir accesos entre tenants y aceptar cambios frecuentes; el otro puede ser lento, frágil y difícil de modificar.
La diferencia está en sus atributos de calidad.
funcionalidad
→ qué resultado ofrece el sistema
atributo de calidad
→ cómo debe ofrecerlo y bajo qué condicionesLos atributos de calidad convierten deseos generales como “debe ser rápido”, “seguro” o “escalable” en comportamientos que pueden influir en decisiones arquitectónicas y luego verificarse.
Los requisitos funcionales suelen describir el camino feliz:
un cliente confirma un pedido
→ el sistema reserva inventario
→ el pedido cambia de estadoPero no responden:
Sin atributos de calidad, la arquitectura se diseña con supuestos implícitos. Cada persona interpreta “rápido”, “seguro” o “disponible” de manera distinta.
Un atributo de calidad puede entenderse como una exigencia observable sobre el sistema:
situación concreta
+ condición o estímulo
+ parte afectada
+ respuesta esperada
+ medida verificablePor ejemplo:
Durante hora pico,
cuando un cajero confirma una venta,
el inventario debe actualizarse sin sobreventa
y responder en menos de 500 ms para el 95 % de operaciones.Aquí aparecen varias cualidades al mismo tiempo:
Los atributos rara vez viven aislados. Una decisión que mejora uno puede empeorar otro.
Describe el tiempo y los recursos necesarios para completar trabajo.
No se limita a “latencia baja”. Incluye:
Una caché puede mejorar lecturas, pero introduce datos obsoletos e invalidación. Ejecutar operaciones en paralelo puede reducir latencia, pero aumentar carga y complejidad de fallo.
Describe la capacidad del sistema para cumplir su propósito cuando se solicita.
No debe expresarse únicamente como un porcentaje global. Es necesario definir:
Un catálogo puede seguir disponible con datos ligeramente antiguos. Un flujo de pago no debe responder “éxito” si no conoce el resultado real.
Es la capacidad de limitar el impacto de fallos y recuperarse.
Incluye:
Disponibilidad y resiliencia están relacionadas, pero no son idénticas. Un sistema puede estar disponible mientras opera degradado; la resiliencia explica cómo conserva funciones y vuelve a un estado saludable.
Busca proteger confidencialidad, integridad, autenticidad, autorización y trazabilidad.
Debe evaluarse según amenazas concretas:
Un control puede reducir riesgo sin eliminarlo. Por eso se utiliza defensa en profundidad: identidad, autorización, aislamiento de datos, auditoría, cifrado y monitoreo.
Describe el costo, alcance y riesgo de realizar cambios.
Una modificación es más sencilla cuando:
Agregar capas siempre puede parecer “más mantenible”, pero si cada cambio atraviesa seis archivos ceremoniales, la modificabilidad empeora.
Es la facilidad para controlar entradas, sustituir dependencias relevantes y observar resultados.
Depende de decisiones como:
La testabilidad no significa poder mockear todo. Un sistema puede tener muchos mocks y seguir sin pruebas reales de base de datos, contratos o concurrencia.
Es la capacidad de inferir el estado interno a partir de señales externas.
No consiste en “tener logs”. Requiere poder responder preguntas no previstas:
Se construye mediante métricas, logs estructurados, trazas, perfiles, IDs de correlación y señales de dominio.
Describe cómo colabora el sistema con otros mediante contratos compatibles.
Incluye:
Dos sistemas pueden intercambiar JSON y seguir siendo incompatibles si interpretan estados o unidades de forma distinta.
También condicionan arquitectura. Latencia percibida, operación offline, recuperación de errores, internacionalización y accesibilidad pueden requerir decisiones de rendering, sincronización, caché y modelo de estado.
No todo atributo tiene la misma importancia arquitectónica.
Por ejemplo, “la pantalla debe usar un color determinado” suele ser un requisito de diseño local. “El sistema debe permitir cambiar branding por tenant sin despliegue” sí puede exigir configuración, caché, validación y ownership.
Una cualidad se vuelve arquitectónicamente significativa cuando afecta estructura, riesgos o decisiones difíciles de cambiar.
Mantener réplicas totalmente coordinadas reduce estados divergentes, pero añade comunicación y puede impedir respuestas durante una partición.
Verificar autorización y cifrar datos consume recursos y añade pasos. El objetivo no es eliminar controles, sino diseñarlos con el costo adecuado y sin duplicación innecesaria.
Puertos, contratos y módulos protegen cambios futuros, pero también añaden conceptos. Solo deben introducirse donde exista una frontera o riesgo real.
Caching reduce latencia y carga, pero permite obsolescencia. La decisión depende del daño causado por datos antiguos.
No todos los atributos pueden tener prioridad máxima.
Una técnica útil es separar:
atributos diferenciadores
→ determinan decisiones principales
atributos con umbral
→ deben alcanzar un nivel suficiente
atributos secundarios
→ se optimizan solo si existe evidenciaPara DomiSys podrían priorizarse:
La disponibilidad multirregional podría no justificar su costo inicial.
Supón que dos cajeros intentan vender la última unidad.
Reservar stock y confirmar la venta.
Una actualización atómica en base de datos puede proteger la invariante:
UPDATE inventory
SET available = available - 1
WHERE product_id = :id
AND tenant_id = :tenant
AND available >= 1;El número de filas afectadas indica si la reserva ocurrió.
Este mecanismo favorece integridad y simplicidad local. Sin embargo, si Inventario fuera un servicio remoto, aparecerían latencia, timeouts y estados inciertos. La misma función exige otra arquitectura dependiendo de las cualidades priorizadas.
Un atributo bien definido debe aclarar qué garantiza y qué no.
Ejemplo:
Garantía:
el 95 % de consultas de catálogo responde en menos de 300 ms
con 500 solicitudes por segundo.
No garantiza:
que cada solicitud individual responda en 300 ms,
ni que el objetivo se conserve con cualquier volumen.Esta precisión evita promesas absolutas imposibles de verificar.
Pruebas de carga representativas, histogramas de latencia, perfiles y análisis de saturación.
Inyección de fallos, simulación de dependencias lentas, pruebas de recuperación y verificación de degradación.
Threat modeling, pruebas de autorización, análisis de dependencias, revisión de secretos y ejercicios de aislamiento.
Cambios de prueba, métricas de lead time, análisis de dependencias y revisión del alcance real de modificaciones.
Capacidad de ejecutar reglas sin infraestructura, pruebas de integración reproducibles y observación clara de fallos.
Preguntas operativas reales: identificar causa, impacto y tenant afectado usando las señales disponibles.
“Rápido”, “robusto” o “escalable” no guían decisiones. Deben convertirse en escenarios.
Si todas las cualidades son críticas, ninguna orienta trade-offs. Se necesita orden y umbrales.
Decidir caching, microservicios o replicación sin definir el problema produce complejidad injustificada.
Los atributos importan especialmente bajo carga, fallo, concurrencia y cambio.
Una arquitectura puede cumplir objetivos técnicos y ser inviable para el equipo que debe operarla.
Escenarios de calidad y tácticas convierte estas cualidades abstractas en situaciones medibles y conecta cada una con mecanismos arquitectónicos concretos.