System Design
Requisitos no funcionales
Explica cómo definir atributos de calidad medibles para rendimiento, disponibilidad, recuperación, seguridad, escalabilidad, accesibilidad y operación.
- Última actualización
- Actualizada
- Nivel
- Fundamentos
System Design
Explica cómo definir atributos de calidad medibles para rendimiento, disponibilidad, recuperación, seguridad, escalabilidad, accesibilidad y operación.
Los requisitos no funcionales no son “extras” ni deseos vagos como rápido, seguro o escalable. Definen las condiciones medibles bajo las cuales una funcionalidad sigue siendo aceptable en producción.
Un sistema puede hacer lo correcto y aun así fracasar porque responde demasiado lento, pierde datos, no puede recuperarse, excluye usuarios o requiere una operación imposible de sostener.
comportamiento correcto
+ calidad suficiente
+ límites conocidos
= resultado realmente útilLos requisitos no funcionales suelen expresarse mejor como escenarios de atributos de calidad que conectan estímulo, entorno, respuesta y medida.
“Crear pedidos” parece completo hasta preguntar:
Sin estas respuestas, la arquitectura optimiza a ciegas o sobrediseña para supuestos imaginarios.
fuente del estímulo
→ estímulo
→ entorno
→ parte afectada
→ respuesta del sistema
→ medida observableEjemplo:
Durante hora pico,
cuando 500 usuarios consultan catálogo simultáneamente,
el sistema responde al 95 % en menos de 400 ms,
con menos de 0.5 % de errores durante 30 minutos.La condición de medición importa tanto como el número. Un p95 sin volumen, dataset, estado de caché y duración es ambiguo.
Funcional
→ el cliente consulta el estado de su pedido
No funcional
→ la consulta responde p95 < 300 ms con 1 000 rpsLa frontera no siempre es absoluta. Seguridad y auditoría pueden expresarse como comportamientos y como cualidades. Lo importante es conservar trazabilidad y verificabilidad.
Define latencia, throughput, consumo o duración bajo una carga conocida.
Métricas comunes:
Promedio de latencia puede ocultar una cola larga. Los percentiles muestran experiencia de usuarios lentos.
Expresa cuánto tiempo una capacidad crítica debe estar utilizable.
99.9 % mensual
≈ hasta 43.8 minutos de indisponibilidad por mesDebe definir alcance: quizá lectura de catálogo tolera degradación, mientras confirmar pago requiere garantías distintas.
Describe exactitud, duplicados, orden, durabilidad y comportamiento bajo reintentos.
Ejemplo: “Un webhook duplicado no crea dos pagos”.
Estos objetivos determinan backups, replicación, runbooks y coste.
Debe partir de amenaza y activo:
usuario comprometido
→ intenta consultar otra sucursal
→ el sistema rechaza y audita“Usar JWT” no es requisito de seguridad; es una alternativa técnica.
Define minimización, retención, propósito, acceso y eliminación. Puede entrar en tensión con auditoría o regulación.
Especifica conformidad y flujos críticos. No basta declarar “WCAG AA” sin probar teclado, lector, contraste, errores y contenido dinámico.
Describe crecimiento esperado y qué debe conservarse sin rediseño fundamental. “Escalar infinitamente” no es útil.
Puede medirse mediante tiempo para desplegar cambios, aislamiento de componentes, cobertura contractual o límites de acoplamiento. Evita métricas cosméticas como cantidad de clases.
Incluye señales, diagnóstico, despliegue, rollback, alertas y soporte. Un sistema sin capacidad de explicar fallos no es operable.
Versiones de clientes, navegadores, formatos, APIs y datos. Debe especificar ventana de soporte y estrategia de deprecación.
Plantilla:
Fuente:
Estímulo:
Entorno:
Artefacto:
Respuesta:
Medida:
Prioridad:
Consecuencia si no se cumple:Ejemplo de resiliencia:
Fuente: proveedor de pagos
Estímulo: timeout durante confirmación
Entorno: operación normal
Artefacto: flujo de checkout
Respuesta: conservar intención pendiente, no duplicar cobro y permitir reconciliación
Medida: recuperación automática en 99 % de casos dentro de 10 minutosLa meta debe derivarse de usuario, negocio o riesgo. No elijas 100 ms porque suena profesional.
Mide sistema o proceso actual. Sin baseline, declara cómo se obtendrá.
No todas las rutas necesitan la misma latencia o disponibilidad.
Volumen, dataset, región, caché, hardware y duración.
Una meta absoluta puede ser inviable. El error budget permite equilibrar confiabilidad y cambio.
Carga, caos controlado, restore drill, auditoría, accesibilidad o revisión de amenazas.
Creación de pedidos:
p95 < 700 ms y p99 < 1.5 s
con 200 rps durante 30 minutos,
menos de 0.2 % de errores técnicos.Consulta de catálogo: 99.95 % mensual.
Confirmación de pedido: 99.9 % mensual.Diferenciar capacidades evita pagar alta disponibilidad extrema para todo.
RPO ≤ 5 minutos.
RTO ≤ 45 minutos.
Restore completo probado trimestralmente.Toda acción administrativa debe requerir autenticación fuerte,
autorización por sucursal y registro auditable inmutable.Un operador debe identificar dependencia degradada y request afectado
en menos de 10 minutos usando dashboards, logs y traces.Coordinar escrituras entre regiones puede aumentar latencia o reducir disponibilidad durante particiones.
MFA y controles protegen, pero pueden ralentizar operaciones. Segmenta por riesgo.
Más réplicas, caché y capacidad reducen latencia, pero elevan coste y complejidad.
Failover automático requiere detección, fencing, pruebas y operación.
Logs ricos ayudan a diagnosticar, pero pueden exponer datos sensibles. Diseña redacción y acceso.
Un requisito debe hacer visible el trade-off, no pretender maximizar todas las cualidades.
Distingue:
La carga debe modelarse con distribución real. 1 000 rps uniformes no representan una venta flash con ráfagas y una sola hot key.
La disponibilidad del flujo completo no puede superar mágicamente la de todas sus dependencias síncronas.
app 99.99 %
× pago 99.9 %
× inventario 99.9 %
→ flujo menor que cada componente aisladoPara mejorar, desacopla, degrada o ofrece alternativas; no solo aumenta réplicas propias.
Una prueba útil incluye:
Optimizar solo una query local no demuestra capacidad end-to-end.
Declara hipótesis y experimento para establecerlo.
Revisa p95/p99 y usuarios críticos.
Disponibilidad no implica confiabilidad semántica.
RPO/RTO son aspiraciones hasta ejecutar restore y failover.
El promedio oculta noisy neighbors y hot partitions.
Registra contrato, monitoreo y alternativa.
No define umbral, carga ni alcance.
Puede generar arquitectura y coste innecesarios.
Ignora errores, degradación y recuperación.
No deja margen para mantenimiento ni incidentes y suele ser físicamente irreal.
Aumenta coste sin valor.
Un sistema puede ser rápido a baja carga y no escalar, o escalar con latencia alta.
“Usar CDN” es diseño. El requisito expresa distribución y latencia.
Cuando cambian impacto, volumen, coste, regulación o evidencia. Una meta incumplida no siempre exige más infraestructura; puede requerir renegociar alcance o segmentar criticidad.
Restricciones, supuestos y dependencias hace visibles los límites que condicionan estos objetivos de calidad.