Preparing materials for an architecture review
What to gather before a backend architecture review so interview time goes to judgment, not scavenger hunts.
The quality of a review tracks the quality of intake. Teams that send a clear context diagram and a decision statement get sharper findings than teams that send a repository dump and hope.
Minimum useful packet
- One-page decision statement: what must be true after this review
- Context diagram with trust boundaries
- List of in-scope services and owners
- Draft or live API specs for the contested surfaces
- Known incidents from the last two quarters that touched those surfaces
Optional but high leverage
- Recent RFC or design doc, even if unfinished
- On-call notes from the last painful night
- A frank note on political constraints (freeze windows, vendor lock, headcount)
What to skip
Pixel-perfect redraws of diagrams for the advisor. Clarity beats polish. We would rather see a photographed whiteboard with correct ownership arrows than a glossy deck with ambiguous boxes.
When you request a review, attach whatever you already have. We will tell you what is missing before the clock on the engagement starts.