Azure / Advanced: secure and recoverable architecture / Lesson 17

Azure architecture decisions and defensible tradeoffs

Build an architecture decision record from business constraints, quality attributes, alternatives, and evidence. Make Azure service choices revisable without treating a score or diagram as proof.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Distinguish hard constraints from preferences.
Record tradeoffs, assumptions, and rejected alternatives.
Use a decision model without fabricating service support.

A useful architecture starts with consequences

Name the user outcome, data sensitivity, residency, recovery objectives, workload pattern, team capability, and expected change. Azure Well-Architected considerations such as reliability, security, cost optimization, operational excellence, and performance efficiency help expose tradeoffs, not create one universal best service. A requirement that data remain in a defined location differs from a preference for a familiar runtime. Capture the consequence of violating each requirement and identify who owns the decision. Do not begin with a product list and then invent requirements that justify it; that makes later review an exercise in defending an untested choice.

An ADR preserves why the decision was reasonable

Record context, options, chosen direction, assumptions, evidence, consequences, and conditions for reconsideration. Keep accepted history and supersede a decision when the context changes instead of silently rewriting the original rationale. The JSON example records a synthetic HTTP workload whose team prefers managed operations while still needing runtime and network verification. It is not a recommendation to purchase a plan or a declaration that all constraints are met. Explicit uncertainty is useful: it shows which next observation could change the decision. A polished diagram without this reasoning can conceal expensive coupling and unowned recovery obligations.

json A synthetic ADR with visible uncertainty

{
  "model": "architecture-decision-record",
  "decision": "evaluate-managed-http-hosting",
  "context": [
    "synthetic-catalog-api",
    "team-does-not-need-cluster-control"
  ],
  "alternatives": [
    "VM-based-hosting",
    "managed-web-hosting",
    "managed-containers"
  ],
  "unverified": [
    "runtime-support",
    "private-dependency-path",
    "recovery-test"
  ],
  "revisit_when": "hard-requirement-or-evidence-changes"
}

Expected output

a candidate decision remains conditional on missing evidence

The record is not a deployment, service capability assertion, or spending authorization.

Reject unsupported candidates before scoring preferences

Use hard constraints to remove candidates that cannot satisfy essential requirements, then compare remaining tradeoffs. The offline model uses invented candidates and Boolean assumptions, selecting only one that meets both modeled private-access and runtime conditions. It is not an Azure service support matrix. A weighted score over subjective labels does not become an exact probability or a proof of fitness. If the support assumption is unverified, mark it unknown rather than converting it to true for convenience. Recheck region, plan, identity, compliance context, and lifecycle before a real service is accepted.

python Offline hard-constraint filtering

candidates = [{"name": "candidate-a", "private_path": True, "runtime": True}, {"name": "candidate-b", "private_path": True, "runtime": False}]
accepted = [item["name"] for item in candidates if item["private_path"] and item["runtime"]]
print(",".join(accepted))

Expected output

candidate-a

The candidate names and capabilities are invented. The program does not discover or validate Azure features.

Review hidden coupling and the cost of reversal

Compute, identity, networking, data partitioning, message contracts, recovery location, and operational ownership interact. A simpler hosting choice may reduce cluster work while increasing dependence on a platform-specific feature. A multi-region design can improve some failure coverage while complicating writes, residency, observability, and incident authority. Review the blast radius of shared subscriptions, identities, DNS, caches, and pipelines. Include migration and rollback limits in the decision, especially irreversible schema or data transformations. Compare realistic alternatives at the same workload and quality requirements rather than using an easy single-region baseline to claim a universally cheaper or safer architecture.

A decision remains maintained as evidence changes

Use a review cadence and triggers such as workload growth, service retirement, changed residency rules, new failure evidence, or a team ownership change. Keep current official documentation with version or review date where relevant. A prototype can establish a narrow property but cannot prove every production behavior, and cloud support can vary by option and region. This course makes no Azure selection through an account and runs no deployment or service benchmark. It teaches how to explain a conditional design, name residual risk, and propose the next authorized observation that would make the decision more defensible.

Common errors and fixes

A subjective score is presented as proof of the best architecture

Why it happens: Preferences and uncertain assumptions are treated as objective measurements.
How to fix it: Separate hard constraints, evidence, and subjective tradeoffs.
Prevent it next time: Record uncertainty and decision ownership explicitly.

Accepted history is rewritten after requirements change

Why it happens: The original context and consequences disappear.
How to fix it: Create a superseding decision and link the old record.
Prevent it next time: Maintain reconsideration triggers with each ADR.

A prototype success is called production-wide assurance

Why it happens: Narrow evidence is expanded beyond its tested conditions.
How to fix it: State the prototype scope and remaining integration risks.
Prevent it next time: Plan representative authorized verification before acceptance.

Check your understanding

1. Why filter hard constraints before weighted preferences?

Show worked solution

A candidate that cannot meet an essential residency, runtime, or recovery requirement should not win because it scores well on convenience. Verify the constraint first and mark unknown support explicitly. Preferences can compare viable candidates, but the score still does not prove real workload fitness.

2. When should the synthetic managed-hosting decision be revisited?