Stop Writing RFCs Like Mystery Novels: Why the Best Design Docs Start with the Conclusion

I spend hours every week reviewing architecture documents. Most of them make my eye twitch.

Engineers love to write Request for Comments (RFCs) like suspense thrillers. They start with the history of the legacy system. They outline the business requirements. They list three possible alternatives. Finally, buried on page seven, they reveal the actual database they want to deploy.

I genuinely do not understand why we teach software engineers to write like this. It is a massive waste of cognitive bandwidth. When you are architecting an enterprise backend, communication failures directly translate into infrastructure failures.

The Working Memory Bottleneck

Think about how a CPU processes instructions. Modern processors rely heavily on branch prediction. They guess which way a conditional statement will go and start executing those instructions early. If the CPU guesses wrong, it has to flush its entire instruction pipeline. That flush wastes expensive clock cycles.

Human readers work exactly the same way.

When you hide the proposed architecture at the bottom of a document, you force the reviewer to load random context into their working memory without knowing how to index it. I am reading your analysis of Postgres versus MongoDB, but I do not know which one you actually picked. My brain is caching useless information. By the time I reach your conclusion, my cognitive pipeline is saturated.

graph TB
  A["Conclusion first"] --> B["Architecture next"]
  B --> C["Impact next"]
  C --> D["Background last"]
  style A fill:#1f78b4,stroke:#333,stroke-width:2px,color:#fff
  style B fill:#33a02c,stroke:#333,stroke-width:2px,color:#fff
  style C fill:#ff7f00,stroke:#333,stroke-width:2px,color:#fff
  style D fill:#6a3d9a,stroke:#333,stroke-width:2px,color:#fff

The Production Cost of a Bored Reviewer

What happens when a senior engineer gets tired of reading a mystery novel? They skim. They rubber stamp the doc with a “Looks Good To Me” and move on.

This is exactly how fatal system design flaws make it into production.

Suppose your RFC proposes a synchronous API call between a microservice in us-east-1 and a legacy database in eu-west-1. If you bury that detail under five pages of JSON schema definitions, the reviewer is going to miss it. They will approve the design without interrogating the network boundaries.

“

Six months later, your system goes live. Every API request requires a transatlantic network hop. The latency forces your web servers to hold their threads open longer. Your connection pools saturate. Your TCP queues back up. Eventually, your application cluster drops offline because a reviewer missed a basic network boundary buried on page seven of a design doc.

Invert the Structure

You have to respect the physical realities of the systems you are building, and you have to respect the time of the people reviewing them.

Drop the narrative arc. Start your RFC with the exact conclusion you want to implement. Allow the reviewer to load the actual architectural reality into their head first. Then they can evaluate the rest of your document against that reality.

Your design docs should follow a strict, inverted structure.

• The TL;DR: State exactly what is changing. “We are moving the user session cache from Redis to DynamoDB.”
• The Architecture: Show the network diagram immediately. Highlight any new network hops, new data stores, or changes to disk I/O patterns.
• The Impact: List the exact hardware and latency costs. “This adds 10 milliseconds of network latency but removes our dependency on a single point of failure.”
• The Background: Put the history, the rejected alternatives, and the business context at the very bottom.

graph LR
  subgraph Reviewer's mental flow
    Start["Open doc"]
    SeeConclusion["See conclusion immediately"]
    UnderstandArchitecture["Understand architecture"]
    EvaluateImpact["Evaluate cost and risk"]
    ReadBackground["Read history/context last"]
  end

  Start --> SeeConclusion --> UnderstandArchitecture --> EvaluateImpact --> ReadBackground

We do not write technical documents to entertain our peers. We write them to expose flaws in our logic before we commit that logic to expensive hardware.

When you state the conclusion first, reviewers can spend their energy interrogating your data synchronization strategies and cloud latency implications instead of trying to solve a literary puzzle.