← Arquitectura de software ETAPA 05 · 24 MIN

Pon a prueba el diseño antes que el sistema

Evalúa una arquitectura con escenarios concretos, preguntas de riesgo y experimentos medibles.

Abrir en el laboratorio ↗

AL TERMINAR, PODRÁS

  • Identificar un punto de sensibilidad y un compromiso
  • Evaluar diseños que compiten frente a un escenario
  • Proponer una evolución reversible con evidencia medible
Recorre el escenario más difícil por el diseño. Un punto de sensibilidad mueve varias cualidades a la vez.

Descripción del diagrama: Un worker se cae a mitad de trabajo → Tiempo de la concesión (depende de); Tiempo de la concesión → Más corto: recupera antes; Tiempo de la concesión → Más corto: más duplicados

Recorre el escenario más difícil

Elige un escenario de alta prioridad y recórrelo a través de la arquitectura propuesta.

En Relay, un worker puede terminar un efecto externo y caerse antes de registrar el éxito. Un reintento puede duplicar ese efecto. Pregunta qué mecanismo evita, detecta o compensa la duplicación y de qué suposición depende.

Idempotencia (idempotency) significa que repetir la misma operación prevista tiene el mismo efecto que hacerla una vez; la etapa Sistemas bajo presión la trata a fondo. Si el proveedor externo no puede garantizar idempotencia, una fila única local por sí sola no garantiza exactamente una acción externa: el proveedor pudo actuar antes de la caída, y el reintento le pide actuar otra vez. Nombrar esa limitación es un resultado de arquitectura más sólido que dibujar una caja extra que diga «confiabilidad».

Busca decisiones que mueven varias cualidades

Un punto de sensibilidad (sensitivity point) es una propiedad de uno o más componentes, o de sus relaciones, que resulta crítica para lograr una respuesta concreta de un atributo de calidad, como la capacidad de una cola o un timeout.

Un punto de compromiso (tradeoff point) afecta a varias cualidades en direcciones opuestas. Lotes más grandes pueden mejorar la tasa de procesamiento (throughput) a costa de más tiempo de espera y más trabajo perdido si hay una caída. Una revisión debe dejar ver esa relación y proponer una medición, no prometer que un patrón siempre gana.

El ATAM del SEI ofrece un enfoque de evaluación estructurado; este laboratorio usa una revisión pequeña de escenarios inspirada en esas preocupaciones, no una evaluación ATAM completa.

Evoluciona con evidencia y un camino de regreso

Cuando cambie la carga de trabajo o el equipo de Relay, vuelve a enunciar los impulsores y compara el diseño existente con el propuesto.

Define un experimento acotado, un umbral de éxito y un camino de reversión (rollback). Para una migración de base de datos, considera la compatibilidad durante el periodo con versiones mezcladas, el rellenado de datos, la validación, el cambio definitivo y la restauración. Considera también qué significa revertir después de que se escribieron datos nuevos: volver a la aplicación anterior quizá no deshaga un cambio de esquema.

La evaluación de la arquitectura continúa después del despliegue, mediante mediciones y revisiones de cambios. Un diagrama por sí solo no es evidencia de rendimiento ni de capacidad de recuperación.

ERROR FRECUENTE

Tratar una revisión de diseño como prueba de que el sistema cumplirá sus objetivos. Los escenarios revelan riesgos; después deben venir mediciones, pruebas (tests) de la implementación y evidencia operativa.

INTÉNTALO TÚ

Para Relay, compara una cola en base de datos y un broker en un escenario de caída de un worker. Nombra una suposición no probada para cada uno y diseña un experimento pequeño para investigarla.

COMPROBACIÓN DE RECUERDO / APLICA LA IDEA

Decide en el laboratorio.

El checkpoint de dos preguntas, tus notas y tu progreso guardado están en el laboratorio. Gratis y sin cuenta.

Abrir en el laboratorio ↗

CONÉCTALO CON RELAY

Revisa Relay con tres escenarios de estrés. Registra los riesgos, la evidencia que aún falta, una revisión del diseño y un plan de reversión o recuperación.