Writing the Alternatives Section in RFCs/Design Docs
Practice writing fair, balanced alternative options sections that show engineering rigor.
Alternatives section language
- Rejected option: name it + acknowledge its benefit + "rejected due to [specific reason]"
- Trade-off framing: each option's benefit AND cost, then decision criterion made explicit
- Criteria: enumerate and define each criterion before evaluating options
- Status quo: always list "do nothing" with its honest benefits and a specific rejection reason
- Recommendation: name the option + root cause addressed + evidence (PoC, data)
Question 0 of 5
Which passage most fairly and professionally presents a rejected alternative in an RFC?
A fair rejected alternative names the option, summarises its benefit, and gives specific technical or resource reasons for rejection — it does not dismiss or insult the option.
- Option named and described — "GraphQL Federation" — specific, not "a different approach".
- Benefit acknowledged — "would provide greater query flexibility" — shows the author genuinely considered the option.
- Specific rejection reason — "operational overhead of running a federation gateway" and "team's current lack of GraphQL expertise" — two distinct, specific reasons a reviewer can evaluate independently.
- Scale qualifier — "outweigh the benefits at our current scale" — honest about the fact that this might be the right choice at a different scale. This is intellectually rigorous.
Which passage correctly uses trade-off framing in an alternatives section?
Trade-off framing explicitly names what each option gains and what it costs — it does not declare a winner without argument.
- Each option's benefit named — "broader client compatibility" (REST), "lower latency and strongly-typed contracts" (gRPC).
- Each option's cost named — "higher payload overhead" (REST), "requires HTTP/2 and generating client stubs" (gRPC).
- Decision criterion made explicit — "our current priority of rapid third-party integration" — the reader can now evaluate the decision: if their priority were different (e.g., internal microservices performance), they might reach a different conclusion.
- "Despite the X trade-off" — acknowledges the cost of the chosen option honestly.
Which passage correctly writes "we evaluated X criteria" vocabulary in an alternatives section?
Criteria vocabulary must enumerate each criterion by name with a one-sentence definition — this prevents readers from applying different interpretations of the same word.
- Number of criteria stated upfront — "four criteria" — the reader knows how many to expect and can verify coverage.
- Each criterion defined — "operational complexity — how much effort is required to deploy, monitor, and maintain" — "complexity" means different things to different people; the parenthetical definition removes ambiguity.
- Measurement method implied — "(4) latency impact — measured from our load test results" — not just "latency", but latency measured in a specific way, which distinguishes it from theoretical latency estimates.
Which passage correctly presents "status quo" as a formal option in an alternatives section?
"Status quo (do nothing)" is a legitimate option that must be named, described, and rejected with a specific reason — not dismissed as obviously unacceptable.
- Named formally — "Option D — Status quo (do nothing)" — gives it the same structure as the other options, signalling the author took it seriously.
- Described honestly — "requires no engineering effort and no operational changes" — these are real benefits of the status quo. Acknowledging them makes the rejection more credible.
- Rejection reason is specific and quantified — "will exceed the database read replica's connection limit within 3 months at the projected growth rate" — this is a concrete forecast, not "it won't scale".
- Consequence named — "resulting in connection errors for all dependent services" — connects the technical failure to a user-visible impact.
Which passage correctly frames the "recommended option" at the end of an alternatives section?
The recommended option closing must name the option, explain why it is preferred over the others, and cite evidence — not just assert preference.
- Explicit label — "Recommended option: Option A (event-driven async processing)" — unambiguous. Readers scanning the document can find the recommendation immediately.
- "Because it directly addresses the root cause" — distinguishes it from options that treat symptoms. This is a principled argument, not personal preference.
- "Aligns with existing infrastructure" — practical consideration: the team does not have to learn or operate something entirely new.
- "Validated in a proof-of-concept... 78% reduction" — empirical evidence that the recommendation is grounded in reality, not theory. This is the strongest possible closing argument for an alternatives section.