Software Architecture
Explica cómo convertir cualidades abstractas en escenarios medibles y relacionarlas con tácticas de rendimiento, resiliencia, seguridad, cambio y testabilidad.
Un atributo de calidad solo puede orientar una arquitectura cuando se convierte en un escenario observable. Las tácticas son los mecanismos concretos que modifican la respuesta del sistema ante ese escenario.
Decir que un sistema debe ser rápido, seguro o modificable no es suficiente. Esas palabras expresan intención, pero no permiten comparar alternativas ni comprobar resultados.
Un escenario de calidad transforma una cualidad abstracta en una situación concreta:
fuente del estímulo
→ estímulo
→ entorno
→ artefacto afectado
→ respuesta del sistema
→ medida de la respuestaUna táctica es una decisión de diseño que influye directamente en esa respuesta. Un patrón puede combinar varias tácticas; una tecnología puede implementarlas; ninguna de las dos reemplaza la necesidad de definir primero el escenario.
Sin escenarios, distintas personas interpretan la misma exigencia de manera diferente.
“la API debe ser rápida”Puede significar:
Cada interpretación conduce a decisiones distintas. Un escenario elimina parte de esa ambigüedad y hace visible el contexto donde la cualidad importa.
Quién o qué genera el estímulo: usuario, servicio, administrador, atacante, fallo de infraestructura o cambio de negocio.
El evento que exige respuesta: una solicitud, una caída, una modificación, un pico de carga o un intento de acceso.
Condiciones relevantes: operación normal, hora pico, despliegue, dependencia degradada, recuperación o ataque.
La parte afectada: servicio, módulo, base de datos, flujo de negocio, región o contrato.
Qué debe hacer el sistema: responder, degradar, rechazar, aislar, recuperar, registrar o permitir un cambio.
Cómo se comprobará: tiempo, porcentaje, volumen, alcance del cambio, pérdida permitida, cantidad de errores o evidencia de auditoría.
Fuente:
clientes de una tienda.
Estímulo:
consultan el catálogo.
Entorno:
hora pico con caché parcialmente fría.
Artefacto:
API de catálogo y persistencia asociada.
Respuesta:
entrega productos autorizados para el tenant y sucursal.
Medida:
p95 menor a 300 ms con 500 solicitudes por segundo,
menos de 1 % de errores y CPU sostenida inferior a 70 %.Este escenario obliga a discutir carga, percentiles, autorización y saturación. Ya no basta con decir “agreguemos Redis”.
Fuente:
equipo de producto.
Estímulo:
agregar un nuevo método de pago.
Entorno:
sistema en producción con consumidores existentes.
Artefacto:
flujo de checkout y contratos de pagos.
Respuesta:
incorporar el proveedor sin cambiar reglas de pedidos ni clientes existentes.
Medida:
cambio implementado y desplegado en menos de tres días,
sin modificar más de un módulo de negocio
y con rollback independiente.Aquí la medida no es rendimiento, sino alcance, tiempo y riesgo del cambio.
Mecanismo que afecta una cualidad concreta.
timeout
→ limita espera y uso de recursosEstructura reusable que agrupa decisiones.
circuit breaker
→ estado cerrado, abierto y semiabierto
→ usa timeouts, medición de fallos y recuperación controladaHerramienta que implementa mecanismos.
Redis
→ puede implementar caché, rate limiting o coordinación
→ no define por sí mismo qué semántica necesita el sistemaLa misma tecnología puede apoyar tácticas distintas. Elegirla antes del escenario puede introducir capacidad innecesaria.
Eliminar trabajo, comprimir payloads, paginar, precalcular o cachear resultados.
El beneficio depende de qué recurso domina el costo. Cachear una respuesta barata puede añadir más complejidad que ahorro.
Pools, concurrencia limitada, particionamiento y escalado aumentan capacidad o distribuyen carga.
Más recursos no corrigen algoritmos ineficientes ni consultas mal diseñadas.
Prioridades, colas, batching y scheduling deciden qué trabajo se ejecuta primero y cuánto puede esperar.
Health checks, heartbeats, timeouts y monitoreo identifican componentes incapaces de cumplir su función.
Un health check mal diseñado puede retirar todas las instancias cuando falla una dependencia secundaria.
Restart, failover, replay, rollback, restauración y reconciliación buscan volver a un estado válido.
La recuperación debe probarse. Un backup no ofrece garantía si nunca se restauró.
Bulkheads, cuotas, circuit breakers y load shedding impiden que un fallo consuma todos los recursos.
Determinar quién realiza la acción mediante sesiones, tokens, certificados o identidades de servicio.
Verificar si esa identidad puede ejecutar la operación sobre el recurso concreto. La autorización debe conservar contexto de tenant, rol y ownership.
Mínimo privilegio, segmentación, cifrado, redacción de datos y superficies públicas pequeñas reducen impacto potencial.
Auditoría, alertas y trazabilidad permiten investigar acciones y responder a incidentes.
Alta cohesión y límites claros reducen el número de partes afectadas.
Interfaces, APIs públicas y reglas de import impiden depender de detalles volátiles.
Feature flags, adapters y configuración permiten conservar opciones sin comprometer prematuramente toda la estructura.
Expand-and-contract, branch by abstraction y Strangler permiten coexistencia temporal y rollback.
No todas las dependencias necesitan mocks. Las tácticas deben permitir la prueba adecuada para cada riesgo.
Ejemplo: durante un pico, las confirmaciones de venta pueden saturar el pool de conexiones.
Las ventas válidas deben conservar integridad y responder antes de que el cajero repita la acción.
300 confirmaciones por segundo
durante diez minutos
con una réplica degradadap95 < 500 ms
0 sobreventas
menos de 0,5 % de errores técnicosLa cola introduce asincronía. El pool limita concurrencia. El load shedding reduce funcionalidad secundaria.
Prueba de carga con contención real, métricas de locks, latencia y errores de dominio.
Escenario:
Durante operación normal,
el proveedor de pagos tarda más de cinco segundos,
el checkout debe finalizar con estado pendiente en menos de dos segundos,
sin cobrar dos veces y permitiendo reconciliación posterior.Tácticas posibles:
pending persistido.Flujo:
cliente confirma
→ sistema registra intento e idempotency key
→ proveedor no responde a tiempo
→ pedido queda pendiente
→ webhook o reconciliación obtiene resultado
→ estado converge sin repetir el cobroLa táctica no elimina la incertidumbre. La transforma en un estado explícito y operable.
El promedio puede ocultar p99 inaceptable. Usa distribuciones y volumen representativo.
Puede dividirse en escenarios coordinados: rendimiento, integridad y recuperación. Deben conservar la relación entre sí.
Hedging reduce tail latency, pero duplica tráfico. Caching mejora lectura, pero reduce frescura. Registra el trade-off.
Una prueba con caché caliente y una sola solicitud no valida el escenario de hora pico.
Define comportamiento propio: timeout, degradación, estado pendiente, fallback o reconciliación.
“99,99 % de disponibilidad” puede no representar el flujo que realmente importa. Mide capacidades de negocio, no solo procesos encendidos.
Agregar caché, retries o replicación sin riesgo definido crea complejidad y fallos nuevos.
Una cualidad puede cumplirse en operación normal y fallar durante despliegue, pico o dependencia degradada.
Si no existe instrumentación ni prueba, el objetivo no puede gobernar decisiones.
Toda táctica consume recursos, añade estado o aumenta complejidad cognitiva y operacional.
La verificación debe usar la misma medida definida por el escenario.
Decisiones arquitectónicas y ADR muestra cómo conservar el contexto, las alternativas y las consecuencias de las decisiones que surgen de estos escenarios.