One option, presented as the only one
A review that sees one option can only approve or reject it. Ask for at least two options, including the simplest, so the trade-off is visible to everyone in the room.
Architecture review request: bring options, not a finished build
An architecture review checks a proposed design against its constraints, including data handling, reliability, security and how the system will be run, and it ends with a recorded decision. A reviewer can only judge what they are shown, so the request needs the problem, at least two options, the one you recommend, and the boundary it touches. Ask for the review while the design can still change, because a review after the build can only record what was done.
What people search
Architecture review: 260 average monthly searches.Google Ads Keyword Planner · 2026-10-09 · United States
Field blueprint
Twelve fields that give reviewers a decision to make
| Field | Type | Required | Why you ask it |
|---|---|---|---|
Requester name | Short text | Required | The person the reviewers can ask about intent before the review. One name avoids a chain of forwarded questions. |
Team and service | Short text | Required | Names the owning team and the service, so the review has someone to answer for the design after it is approved. |
Review typeNew system or serviceSignificant change to an existing systemNew dependency on another team's systemData store or migration changeOther | Single choice | Required | Tells the reviewers which constraints matter most. A migration and a new public API raise different questions. |
What problem does this design solve? | Long text | Required | The need in one or two sentences. A design without a stated problem can only be judged by taste. |
Options you consideredList each option in a sentence, with its main cost. | Long text | Required | At least two, including the simplest option or doing nothing. A review that sees one option can only approve or reject it. |
Option you recommend, and why | Long text | Required | The trade-off you chose and the reason. Reviewers can then challenge the reason, which is the useful part. |
Systems, data stores and teams it touchesUse names, not addresses, connection strings or credentials. | Long text | Required | Sets the boundary of the review and shows who else needs to hear the decision. |
Data involvedNo personal dataPersonal data for internal useCustomer personal dataNot sure, needs a data review | Single choice | Required | Decides whether a privacy or security reviewer must join before the design is approved. |
What happens when a dependency is slow or down? | Long text | Required | What users see and what the system does on failure. A design is judged on its failures as much as its happy path. |
Link to the diagramPaste a link to a diagram the reviewers can open. https:// | Short text | Optional | The picture reviewers open first. Keep it current, because an old diagram misleads more than having none. |
Decision needed by | Date | Required | The date the team needs a decision to keep its schedule. Reviewers can plan around a real date. |
Reviewers you want in the room | Short text | Optional | Names people or roles, such as the security lead or the data platform owner. Saves a round of asking who should have been there. |
At a glance
What the requester needs to complete
12Fields
10Required fields
7Estimated time (minutes)
Estimate based on question types; actual completion time varies.
Try it
Try the request as a service owner would
After a response arrives
What happens after a request is sent
A scheduled job comes before any notice
The creator is told after the hourly processing run in production finishes. Send a request a few days before the review slot, not on the morning of it.
Check each request before booking a slot
Check the review type, the data involved and the decision date. Bring in a privacy or security reviewer before the slot is booked when customer personal data is involved.
Record the outcome in your decision log
The form holds the request but does not track the outcome. Write the decision, its conditions and the owner in your decision log, and link the request from it.
Export for the review calendar
Export the responses to CSV to plan the review calendar. Keep the export internal, because it describes systems and data flows that are not public.
Mistakes to avoid
Requests that send a review back
No one named to run it
A design that nobody will operate once it is live has an ownership gap, not only a design gap. Name the team that carries the on-call and the runbook before the review.
Asking for review after the build
A review that happens after the code has shipped can only record what was done. Request the review while the design is still open to change, and say which parts are fixed.
No failure behavior
A request with only a happy path has not been reviewed for a dependency that is down. Ask the requester to describe the failure behavior before the review is scheduled.
Frequently asked questions
What is an architecture review?
It is a structured check of a proposed design against its constraints, such as data handling, reliability, security, cost and how the system will be run. It ends with a recorded decision and any conditions, not with a general discussion. Bring the options you considered and the one you recommend.
Is there an architecture review request form template I can download?
Nothing downloadable here is a Word or PDF template. The guide sets out the questions and their order, and Attain OS publishes the request as a link for requesters to answer on the web. Keep the diagram and the decision record in the tools your team already uses.
Does every design need an architecture review?
Some teams set a threshold, such as a change that crosses a service boundary, touches customer data or adds a new dependency, and they write it down so people know when a request is required. Set your own threshold rather than copying someone else's.
Should the architecture diagram be attached to the request?
Not as a file, since the form has no file upload field. Link to the diagram instead, and keep it current. An outdated diagram does more harm than no diagram.
Browse by category
More requests in Product & Engineering
Requests
Design/UI Request
Requests
API Access Request
Applications
Beta Tester Signup
Reports
External Bug Report
Surveys
Product Feedback
Checklists
Release Sign-off
How to build it
Choose a category and a form type in the wizard. Answer three Atty Suggestions questions, then give the form a title. Atty builds the fields in the background. Edit the fields and ask Atty to refine them, then publish and share the /f/ link.
