# Architecture Tactics

> Tactics per quality attribute (availability, modifiability, performance, security, safety, ...), how to choose and combine tactics.

## Tactics: concepts and how to use them

- [Architectural Tactic](https://arc.fuet.ch/concepts/tactics/architectural-tactic.md): An architectural tactic is a design decision that affects how well a software architecture addresses a quality attribute. Tactics work by adjusting parameters of a quality attribute model, and architectural patterns are built from them.
- [Choosing and Applying Tactics](https://arc.fuet.ch/concepts/tactics/choosing-and-applying-tactics.md): Choosing tactics means picking design decisions that serve quality requirements you already captured. You then build patterns from them and handle the side effects each choice has on other qualities.
- [Reasons for Architectural Tactics](https://arc.fuet.ch/concepts/tactics/reasons-for-architectural-tactics.md): Patterns rarely fit a design context perfectly. Tactics are smaller building blocks that help architects adapt a pattern and reason about one quality goal at a time.
- [Relationship between Tactics and Architectural Styles/Patterns](https://arc.fuet.ch/concepts/tactics/tactics-vs-architectural-styles-and-patterns.md): A tactic is a single design decision that influences one quality attribute response. A pattern is a solution to a recurring problem. Patterns are made of smaller tactic-level decisions, like molecules from atoms.
- [Scenario-based Questions from Tactics](https://arc.fuet.ch/concepts/tactics/scenario-based-questions-from-tactics.md): A questionnaire asks general, open questions that fit any architecture. A scenario describes a concrete sequence of steps in which the system is used or changed. Scenario-based questions lean on the second idea.
- [Tactic Coverage of ISO 25010 Quality Categories](https://arc.fuet.ch/concepts/tactics/tactic-sources-by-iso-25010-quality-category.md): Tactic catalogs and ISO 25010 use different vocabularies. Catalogs cover terms the 2011 standard lacks, such as deployability and energy efficiency, so you must map one to the other before judging coverage.
- [Tactic Trade-off Balancing](https://arc.fuet.ch/concepts/tactics/tactic-trade-off-balancing.md): Tactics serve quality goals, and those goals can conflict. Balancing means ranking the goals, finding where they collide, and recording each choice with all its consequences.
- [Working with Tactics and Quality Attributes](https://arc.fuet.ch/concepts/tactics/working-with-tactics-and-quality-attributes.md): Working with tactics means taking measurable quality scenarios and choosing small design decisions (tactics) that meet them. You record each choice with its reasoning and revisit it as knowledge grows.

## Availability tactics

- [Active Redundancy](https://arc.fuet.ch/concepts/tactics/active-redundancy.md): Active redundancy keeps spare components running alongside the working ones, all processing the same inputs. A spare can take over within milliseconds. This gives the fastest recovery, but it costs the most.
- [Availability Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactic.md): Availability tactics are design measures that keep faults from turning into failures. They fall into three groups: detecting faults, recovering from faults, and preventing faults.
- [Availability Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics.md): An availability tactic is a design measure that controls how a system reacts to faults. Architects combine such measures to recover from faults, so the system keeps serving users.
- [Availability Tactic Categories](https://arc.fuet.ch/concepts/tactics/availability-responses.md): Availability tactics fall into three groups: detect faults, recover from faults, and prevent faults. Architects combine tactics from all three groups to meet an availability goal, and they weigh each choice against cost and complexity.
- [Circuit Breaker](https://arc.fuet.ch/concepts/tactics/circuit-breaker.md): A circuit breaker sits between a caller and a service it depends on. After repeated failures it fails calls at once instead of waiting. It later tests the service and resumes when the service recovers.
- [Exception Handling Tactic](https://arc.fuet.ch/concepts/tactics/exception-handling.md): Exception handling means the system reacts to a detected fault by reporting it or handling it. It is a recovery tactic for availability and follows fault detection.
- [Fault Detection Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics-fault-detection.md): Fault detection tactics spot a problem before it grows into a failure users can see. Common techniques are ping/echo, heartbeat, monitors, time stamps, condition monitoring, voting and exception detection.
- [Fault Prevention Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics-fault-prevention.md): Fault prevention is one of three groups of availability tactics. Its tactics stop faults from happening or from turning into failures, instead of reacting afterward.
- [Fault Recovery Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics-fault-recovery.md): Fault recovery tactics restore service after a fault is found. They prepare spares or retries, repair the problem, and bring repaired parts back into service.
- [Graceful Degradation](https://arc.fuet.ch/concepts/tactics/graceful-degradation.md): Graceful degradation keeps a system's most important functions working when parts fail. It drops or reduces less important features instead of failing completely.
- [Heartbeat](https://arc.fuet.ch/concepts/tactics/heartbeat.md): Heartbeat is an availability tactic for spotting failures. One component sends a message at regular intervals and another listens. If the messages stop, the listener assumes the sender failed and triggers fault correction.
- [Ping/Echo](https://arc.fuet.ch/concepts/tactics/ping-echo.md): Ping/echo checks whether a component is alive. One part sends a request and waits for a reply. If no echo arrives within a set time, the sender declares a failure.
- [Redundant Spare](https://arc.fuet.ch/concepts/tactics/redundant-spare.md): A redundant spare is a duplicate component that takes over when the primary fails. Hot, warm, and cold spares differ in how fast they take over. Faster recovery costs more and adds complexity.
- [Retry](https://arc.fuet.ch/concepts/tactics/retry.md): Retry repeats a failed call after a delay, assuming the fault is temporary. It needs a cap on attempts, growing delays, and care with operations that are unsafe to run twice.
- [Voting](https://arc.fuet.ch/concepts/tactics/voting.md): Voting compares the outputs of several redundant units and uses the majority result. A disagreement reveals a fault, and with three units one faulty result is outvoted.

## Modifiability tactics

- [Increase Cohesion](https://arc.fuet.ch/concepts/tactics/increase-cohesion.md): Increase Cohesion is one of three groups of modifiability tactics. It keeps related responsibilities together and separates unrelated ones, so future changes cost less.
- [Modifiability Tactic](https://arc.fuet.ch/concepts/tactics/modifiability-tactics.md): Modifiability tactics are design decisions that keep the cost of changes low. They fall into three groups: increase cohesion, reduce coupling, and defer binding.
- [Modifiability Tactics in SOA](https://arc.fuet.ch/concepts/tactics/modifiability-tactics-in-soa.md): In service-based systems, intermediaries such as message buses, publish-subscribe channels, and registries sit between providers and consumers. Each side can then change without breaking the other, at some cost to performance and security.
- [Reduce Coupling](https://arc.fuet.ch/concepts/tactics/reduce-coupling.md): Reduce Coupling is a group of modifiability tactics. They lower the dependencies between modules, so a change in one module breaks fewer of the others.
- [Split Module](https://arc.fuet.ch/concepts/tactics/split-module.md): Split Module breaks a module that mixes unrelated responsibilities into smaller modules, so each part changes for its own reason. The split must follow expected change, and it adds interfaces, so weigh it against joining.

## Performance, security, safety, usability and energy tactics

- [Aggregate Tactic](https://arc.fuet.ch/concepts/tactics/aggregate-tactic.md): The aggregate tactic follows the bulk idea: handle many items in one operation instead of one by one. At service level, the same idea appears as a request bundle. It is unrelated to the DDD aggregate and the Aggregator pattern.
- [Encrypt Data](https://arc.fuet.ch/concepts/tactics/encrypt-data.md): Encrypting data scrambles it so only holders of the right key can read it. It protects stored data beyond access control and protects data moving over networks. Careful key management makes it work.
- [Energy Efficiency Tactic](https://arc.fuet.ch/concepts/tactics/energy-efficiency-tactics.md): Energy efficiency tactics are design moves that cut the energy software uses while it still does its job. They help you measure energy use, schedule work well across resources, and reduce the work each event causes.
- [Integrability, Deployability, Testability and Reliability Tactics](https://arc.fuet.ch/concepts/tactics/integrability-deployability-and-testability-tactics.md): Tactics are design decisions grouped by the quality goal they serve. This article covers a few: heartbeat for fault detection, plus rollback, blue/green deployment and feature toggles for safe releases.
- [Load Balancer](https://arc.fuet.ch/concepts/tactics/load-balancer.md): A load balancer spreads incoming requests across several backend servers. It uses resources evenly, helps keep response times low, avoids overload, and can hide a failed server from clients.
- [Performance Tactic](https://arc.fuet.ch/concepts/tactics/performance-tactics.md): Performance tactics are design decisions that help a system answer requests fast enough. They work in two ways: limiting the demand placed on the system, or managing the available resources better.
- [Safety Tactic](https://arc.fuet.ch/concepts/tactics/safety-tactics.md): Safety tactics help a system stay in control of known hazards. They detect problems, contain them with barriers or redundancy, and fall back to a safe state when needed. Examples are interlocks, watchdogs, timeouts and fail-safe defaults.
- [Security Tactic](https://arc.fuet.ch/concepts/tactics/security-tactics.md): Security tactics are design decisions for protecting a system. They borrow ideas from physical security and fall into four categories. Patterns can realize them, and stakeholders can choose them together.
- [Usability Tactic](https://arc.fuet.ch/concepts/tactics/usability-tactics.md): Usability tactics are design choices that help users interact with a system well. Features such as cancel, undo and progress bars need architectural support, so teams must plan them early.