Solution Options Analysis & Trade-offs

Options analysis lays out 2-3 realistic ways to solve a scoped problem, compares them honestly, and writes down why one was picked.

At a glance

• What it is: Identifying a small set of realistic solution options, comparing their trade-offs, and recording the decision — including why the alternatives were rejected — in an ADR (Architecture Decision Record).
• Why it matters: without a written comparison, teams tend to build whatever the first engineer thought of, and future teams have no record of why other approaches weren’t chosen.
• For developers: an ADR is the thing to check before you ask “why didn’t we just do X” — if the answer isn’t written down, that’s a gap worth flagging, not re-litigating from scratch.
• When to use it: right after Requirements Elicitation & Solution Scoping, before any Component & Integration Design begins.
• When not to use it: for decisions with only one realistic option — don’t manufacture false alternatives just to fill out a template.
• Prerequisites: a written problem statement from the scoping step.

Mental model

flowchart LR
    A[Scoped problem] --> B[Option 1]
    A --> C[Option 2]
    A --> D[Option 3]
    B --> E[Compare trade-offs]
    C --> E
    D --> E
    E --> F[Decision + ADR]

Options funnel into one recorded decision. The ADR captures not just what was chosen, but the trade-offs that ruled out the alternatives — so the reasoning survives even after the people involved move on.

Step-by-step walkthrough

1. Take the scoped problem statement and brainstorm every realistic way to solve it.
2. Narrow to 2-3 options worth serious comparison — discard options that are clearly infeasible.
3. Compare options against the same criteria (cost, delivery time, risk, fit with existing systems, and any Non-Functional Requirements already known).
4. Choose one option and write an ADR: context, options considered, decision, and consequences.
5. Share the ADR with stakeholders before moving into detailed design.

Worked example

The retail checkout problem (scoped as “payment confirmation times out under flash-sale load on web checkout”) has two realistic options.

• Input: option A — scale the existing checkout monolith horizontally; option B — extract payment confirmation into its own service behind a queue.
• Process: compare cost (A is cheaper short-term), delivery time (A is faster), and risk under peak load (B isolates the failure and can be scaled independently, A risks the whole monolith degrading).
• Output: ADR choosing option B, documenting that A was rejected because a slow payment step would otherwise still risk taking down unrelated checkout functionality during the exact traffic spikes it needs to survive. On Azure, option B is recorded as a new payment-confirmation service behind an Azure Service Bus queue, autoscaled independently of the checkout monolith on Azure Container Apps.

Common use cases

Use case	When to use	Notes
Choosing an integration pattern	Sync API call vs. async messaging for a new dependency	Compare against the NFRs already known for the initiative
Justifying a costly option to leadership	The best technical option isn’t the cheapest	The ADR’s consequences section is the artifact leadership actually reads
Revisiting a past decision	Circumstances have changed since the original ADR	Write a new ADR that supersedes the old one — don’t silently overturn it
Choosing single-region vs. multi-region deployment	Availability NFR requires surviving a full regional outage	Compare against RTO/RPO targets and cost, not availability alone — see Non-Functional Requirements for the failover-group example

Advanced details

• Write rejected options down, not just the winner: an ADR that only records the decision loses the most useful part — why the alternatives didn’t work.
• Keep the criteria consistent: comparing options against different criteria makes the comparison meaningless; fix the criteria list before scoring.
• ADRs are immutable history: if a decision changes later, write a new ADR that supersedes the old one rather than editing it.
• Score options against a named framework, not gut feel: ByteByteGo’s 10 System Design Tradeoffs You Cannot Ignore catalogs the recurring axes options usually differ on — consistency vs. availability, latency vs. throughput, and cost vs. resilience among them. Scoring options against these named axes makes the comparison repeatable across different decisions.

Quick reference

Term	Meaning
ADR (Architecture Decision Record)	A short written record of a design decision, the options considered, and why one was chosen
Trade-off	A benefit gained by one option at the cost of a downside elsewhere (e.g. faster delivery vs. higher long-term risk)
Superseded ADR	An older ADR whose decision has been replaced by a newer one, kept for history rather than deleted
RTO / RPO	Recovery Time Objective / Recovery Point Objective — how long recovery may take, and how much data loss is acceptable, when comparing deployment options

Troubleshooting

Symptom	Likely cause	Fix
Team keeps re-debating a settled decision	No ADR exists, or it isn’t discoverable	Write the ADR and store it where the team will find it (e.g. alongside the code or in the architecture repository)
Chosen option turns out costlier than expected	Comparison used inconsistent or incomplete criteria	Redo the comparison with a fixed criteria list including NFRs and long-term cost
Stakeholders keep asking “why not X”	The rejected option’s trade-offs were never written down	Add rejected alternatives and their trade-offs to the ADR, not just the chosen option

Check your understanding

• Why should an ADR record rejected options, not just the final decision?
• Take a recent technical decision you made and write it as a 4-part ADR: context, options, decision, consequences.

Related pages

Part of Introduction to Solution Architecture. Follows Requirements Elicitation & Solution Scoping; feeds into Non-Functional Requirements and Component & Integration Design. See also the Glossary.