Architectural Tactics
Intención y alcance
Architectural Tactic es una decisión de diseño relativamente enfocada en modificar una respuesta del sistema para alcanzar una quality requerida. Permite conectar un estímulo y su medida esperada con decisiones que podrían influir en ellos.
La relación entre escenarios, tácticas y diseño se estudia en SEI: Deriving Architectural Tactics. El foco es razonar sobre el efecto de una decisión, no seleccionar mecanismos por popularidad.
Por ejemplo, introducir redundancia puede ayudar a mantener una capacidad cuando falla una instancia. Su utilidad depende de qué falla, dónde permanece el estado y cómo continúa el trabajo. La intención enfocada orienta preguntas; todavía no constituye una implementación ni evidencia de satisfacción.
Del escenario a una hipótesis de diseño
quality-attribute-scenarios identifica Source, Stimulus, Artifact, Environment, Response y Response Measure. Una táctica candidata debe poder explicar qué parte de esa respuesta modifica y bajo qué supuestos.
Si el escenario pide continuidad ante un fallo de instancia, conviene examinar qué capacidad debe sobrevivir y qué recursos necesita. Si el problema es latencia de consultas repetidas, la decisión puede buscar reducir trabajo efectivo o evitar una dependencia lenta.
La explicación debería tener una forma causal: cambiamos esta propiedad de la colaboración, esperamos este efecto en la respuesta y lo evaluaremos bajo estas condiciones. «Usaremos un patrón conocido» no permite reconstruir esa relación.
utility-trees ayuda a priorizar dónde investigar. La importancia del escenario no valida automáticamente una táctica: puede aumentar la necesidad de comprobarla con cuidado y de contrastar alternativas.
Tactic frente a Pattern
Una tactic enfoca una decisión que influye en una quality response. Un pattern describe una solución recurrente con contexto, responsabilidades, colaboración y consecuencias. architectural-pattern y design-pattern preservan esos marcos y sus diferencias de alcance.
Un pattern puede incorporar varias tactics; una tactic puede aparecer en patterns diferentes. Por ejemplo, aislar ciertos recursos puede participar en una colaboración concreta y también en una organización arquitectónica más amplia.
La frontera no es una taxonomía universal perfecta. Las fuentes pueden nombrar una solución como mecanismo, táctica o patrón según qué abstraen y qué problema analizan. Conviene declarar el marco, en vez de resolver ambigüedad cambiando silenciosamente la definición de otro documento.
En el Atlas, examinar una lectura táctica de bulkhead no exige cambiar su metadata ni su canonical. El documento existente conserva estructura y límites; esta página explica cómo relacionar una decisión con escenarios de calidad.
Tactic frente a Architecture Profile
architecture-profile es la convención del Atlas para describir paquetes de decisiones sobre múltiples ejes. microservices no equivale a una architectural tactic: reúne compromisos sobre boundaries, comunicación, datos, deployment y operación.
Dentro de ese profile pueden adoptarse tactics para disponibilidad, modificabilidad, performance o seguridad. También pueden existir en modular-monolith. La etiqueta del profile no selecciona una táctica ni garantiza su efecto.
Si un escenario exige integrar otro proveedor sin cambios dispersos, podemos examinar contratos y localización de responsabilidades en varios profiles. Elegir Microservices solamente por modificabilidad salta desde una preocupación general a un paquete completo, sin comparar sus otras consecuencias.
Tactic frente a mecanismo de implementación
«Introducir redundancia» expresa una decisión enfocada. «Desplegar tres réplicas detrás de un load balancer» concreta recursos y colaboración. La segunda requiere más decisiones: distribución, estado, detección de fallo, routing y recuperación.
Tres réplicas que dependen del mismo recurso defectuoso pueden fallar juntas. El mecanismo no demuestra independencia de fallo. El número elegido tampoco sustituye el escenario que define qué población y capacidades deben continuar.
No toda configuration option merece llamarse tactic. Un valor puede implementar parte de una decisión, ajustar un mecanismo existente o afectar una propiedad significativa. Hay que reconstruir su propósito y el efecto esperado antes de darle una categoría arquitectónica.
El SEI trata las tácticas como decisiones fundamentales que participan tanto en diseño como en análisis. Realizing and Refining Architectural Tactics: Availability. La concreción útil depende de la pregunta y de la arquitectura evaluada.
Lecturas tácticas de soluciones existentes
La tabla ofrece interpretaciones ilustrativas, no equivalencias con un catálogo normativo ni reclasificaciones editoriales.
| Documento existente | Decisión que podemos examinar | Respuesta o consecuencia relevante |
|---|---|---|
| retry | Repetir trabajo bajo condiciones controladas. | Recuperación ante ciertos fallos transitorios y carga adicional. |
| timeout | Limitar la espera del consumidor. | Presupuesto de respuesta, sin probar cancelación remota. |
| circuit-breaker | Controlar admisión hacia una dependencia problemática. | Protección y rechazo observable de trabajo. |
| bulkhead | Separar presupuestos de recursos entre poblaciones. | Contención de agotamiento y costo de fragmentación. |
| backpressure | Propagar información de capacidad para regular producción. | Menor acumulación cuando el productor coopera. |
| load-shedding | Rechazar trabajo seleccionado ante presión. | Protección de capacidad a cambio de trabajo no atendido. |
| transactional-outbox | Conservar una intención durable separando confirmación y entrega posterior. | Recuperación de publicación y obligación de manejar duplicados. |
Cada canonical desarrolla las condiciones reales de su solución. La lectura táctica pregunta qué contribución esperamos en este sistema. No corresponde copiar aquí sus algoritmos, políticas de operación o garantías completas.
Una misma decisión puede participar en varias respuestas. Limitar espera puede mejorar previsibilidad para un cliente y dejar trabajo pendiente en otro componente. El análisis necesita considerar esa frontera, además del efecto local que motivó la decisión.
Podemos formular otras hipótesis situadas: una intervención acotada puede favorecer operability; una traducción explícita de estados, interoperability; localizar detalles de plataforma, portability. Son ejemplos de razonamiento, no una nueva taxonomía normativa. La evidencia debe comprobar tarea, significado o traslado, respectivamente, junto con los costos de controles y contratos.
Una táctica no garantiza la quality
Agregar caching puede reducir ciertas latencias, pero también afectar freshness, memoria y complejidad de invalidación. Una cache fría puede no mejorar la respuesta que importa. Si el workload tiene pocas consultas repetidas, el costo añadido puede superar el ahorro.
La hipótesis debe indicar qué trabajo evitamos y bajo qué patrón de uso. También qué validez admite el resultado y qué ocurre ante misses o presión de memoria. No hace falta convertir este canonical en un artículo de caching para reconocer esos supuestos.
Algo similar ocurre con redundancia: las instancias adicionales necesitan compartir o recuperar la información requerida y tolerar el fallo considerado. «Hay varias» no demuestra disponibilidad, del mismo modo que «hay caching» no demuestra satisfacer performance.
quality-attribute-trade-offs permite comparar consecuencias conjuntas. El resultado puede ser adoptar, modificar, combinar o rechazar la táctica; no hay una obligación de implementar alguna para completar una categoría.
Eliminar trabajo innecesario puede favorecer cost-efficiency y sustainability si se preserva el servicio. El efecto necesita comprobar consumo y costos en una frontera definida; una métrica de CPU por sí sola no demuestra reducción proporcional de emisiones. Esta lectura situada no agrega una taxonomía ni reclasifica patrones.
Composición, evidencia y revisión
Las tactics pueden interactuar. Repetir trabajo con esperas largas puede conservar presión en una dependencia; limitar admisión puede reducir carga y aumentar rechazos. Una evaluación aislada puede perder precisamente la interacción que determina el resultado.
En un ejemplo propio, mejorar la búsqueda mediante reutilización y más capacidad necesita escenarios de resultados repetidos, cache fría y fallo de instancia. Elegir solo el caso favorable permite afirmar una mejora local, pero no que el conjunto satisface todas las prioridades.
La evidencia puede combinar análisis de dependencias, modelos, pruebas dirigidas y observación. Debe guardar relación con la respuesta esperada. Medir CPU sin medir el resultado del usuario puede ayudar al diagnóstico y seguir siendo insuficiente para validar el escenario.
Una revisión proporcionada identifica decisión, efecto esperado, supuestos, consecuencias secundarias y evidencia pendiente. Después vuelve a architectural-drivers si aparecen necesidades o restricciones nuevas. No requiere una plataforma de evaluación para cada ajuste.
Uso, límites y errores frecuentes
Este marco aporta cuando queremos justificar una decisión enfocada y comprobar su contribución. No obliga a convertir cada línea o parámetro en un documento táctico independiente.
Errores frecuentes incluyen llamar tactic a un profile entero, confundir tecnología con resultado y afirmar calidad por presencia de un mecanismo. También sumar soluciones sin revisar interacción o reclasificar patterns existentes solo porque ahora se observan desde otro marco.
quality-attributes-overview mantiene el contexto arquitectónico y quality-attributes organiza la navegación. El criterio final es explicar qué respuesta cambia, por qué debería cambiar y qué evidencia permite confiar en esa explicación dentro de límites explícitos.