The Quality Tactics Catalog

Overview

A style sets the gross shape. Inside it, the quality attributes from Module 2 are achieved — or missed — by a set of much smaller decisions.

Those decisions have names, they form a known catalog, and the architect’s job is to select from it deliberately rather than to arrive at the same moves by accident three months later.

What a tactic is, and why a catalog beats cleverness

A quality tactic is a design move that promotes one specific quality attribute. Redundancy promotes availability. Partitioning promotes scalability. Each is small, each is well understood, and none is novel.

The catalog’s value is not that it contains ideas you have never heard of. It is threefold, and the third item is the one that matters:

• Completeness — you can check whether you have considered the available moves for a quality attribute, rather than reaching for the first one you remember.
• Naming — a named move can be discussed, written in an ADR, and challenged. An unnamed one just happens.
• Comparability — tactics within a group can be compared by cost, and the cost is almost always paid in a different quality attribute.

That last point is the whole topic. Tactics are not improvements; they are transfers. The catalog is useful because it makes the transfer visible.

graph LR
  AV["Availability"] --> AV1["Redundancy and failover<br/><i>costs: money, and<br/>consistency</i>"]
  AV --> AV2["Health monitoring<br/><i>costs: nothing, unless<br/>nobody acts on it</i>"]
  AV --> AV3["Graceful degradation<br/><i>costs: a product decision<br/>about what to drop</i>"]
  PE["Performance"] --> PE1["Caching<br/><i>costs: freshness</i>"]
  PE --> PE2["Concurrency<br/><i>costs: reasoning</i>"]
  SC["Scalability"] --> SC1["Partitioning<br/><i>costs: a key you<br/>cannot easily change</i>"]
  SC --> SC2["Statelessness<br/><i>costs: the state has<br/>to live somewhere else</i>"]

  classDef qa fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef cheap fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  classDef spends fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef hard fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  class AV,PE,SC qa
  class AV2 cheap
  class AV1,AV3,PE1,PE2,SC2 spends
  class SC1 hard

Three quality attributes and the moves available to each. Amber marks a tactic that spends another quality attribute; terracotta marks the one that is genuinely hard to reverse.

Availability

Redundancy and failover is the obvious one and the one whose cost is most often understated. You pay in money and in consistency: the moment there are two of something that can both accept writes, you have taken on a distributed-systems problem that is assumed knowledge here and that does not go away because the diagram looks symmetric.

Health monitoring is close to free and routinely wasted. A health check that nothing acts on is instrumentation, not a tactic. The move is “detect and respond”; half of it is theatre.

Graceful degradation — serving a reduced version of the service rather than failing — is the highest-leverage availability tactic in most systems, and the one architects most often leave to implementers. That is a mistake, because it is not a technical decision. Which functionality to drop is a product question with a business owner, and if you do not decide it in advance, it gets decided at 03:00 by whoever is on call.

Performance

Caching buys the largest performance wins available and spends freshness. At strategy altitude the only questions that matter are where it sits and what staleness is acceptable — and the second one is a requirement, not an implementation detail.

Concurrency and resource management buy throughput and spend the ability to reason about the system. That cost is real and it is paid by every future maintainer, not by you.

Scalability

Statelessness is what makes horizontal scaling cheap, and its cost is simply that the state goes somewhere else. The tactic does not eliminate state; it relocates it, usually into a store that now becomes the bottleneck you were trying to avoid.

Partitioning deserves its own warning. It is the most effective scalability tactic available and the hardest decision to reverse in this entire catalog, because a partition key becomes embedded in access patterns, in operational tooling, and in people’s mental models. Choosing it is a Module 1 “expensive to change later” decision in its purest form, and it should be made against measured numbers rather than projected ones.

Elasticity buys the ability to absorb spikes and spends predictability: cost becomes a function of traffic, and at high steady volume it is usually more expensive than provisioned capacity, not less.

The discipline: name the move and its cost, in the same sentence

A design document that says “we will use caching and redundancy” has recorded nothing. One that says “we cache retrieved documents for one hour, accepting that a documentation change takes up to an hour to appear, because the alternative breaks the cost ceiling” has recorded a decision, its cost, and the requirement that forced it.

That sentence form — tactic, cost, requirement — is the entire deliverable of this topic, and it is what makes an ADR in Module 9 worth reading.

Two tactics, chosen on purpose

Tactic 1 — graceful degradation on the retrieval path. When the documentation index is stale or the model provider is unavailable, the platform returns the top matching documentation links with no generated answer, rather than erroring or guessing.

What it costs: a visibly worse experience during degradation, a second code path to maintain and test, and a product decision from Maya Ortiz about whether links-only counts as a deflection. It also sets up the handoff path the 45 agents inherit, so Grace Adeyemi has to agree to it.

Tactic 2 — cache retrieved context, with a one-hour staleness bound. Repeat questions are common in a corpus where 38% of tickets are already answerable from the docs, so caching is the single largest lever on the $1.54 per-interaction ceiling.

What it costs: up to an hour of staleness after a documentation change — which directly contradicts the Module 2 scenario about answering correctly from documentation updated within the last seven days. The contradiction is resolved by invalidating on publish rather than by shortening the window, and that resolution is itself an architectural decision with a cost: the docs pipeline now has to emit an event the platform listens for, which is a new coupling between two systems that previously knew nothing about each other.

Notice that the second tactic’s real cost was not latency or money. It was a new dependency between two teams — which is the kind of cost that only shows up when you write the sentence out in full.

Feeds the workbook

The rubric requires at least two quality tactics named as deliberate choices with their costs stated. Use the tactic, cost, requirement sentence form, and tie each to an ASR rather than to a general desire for the system to be good.

Check your understanding

1. Pick an availability tactic for the case system and write the full sentence — tactic, cost, requirement. Which part was hardest to fill in?
2. Your caching tactic contradicts a freshness scenario from Module 2. What are your three options, and which quality attribute does each one spend?
3. Which tactic in the catalog would be most expensive to reverse in a system you have worked on, and was that visible when it was chosen?

---

→ This catalog was built for components that behave the same way twice. Two additions are needed for the parts that do not. — Tactics for probabilistic parts