System components
Draw the key components of the proposed architecture: services, databases, queues, caches, third-party APIs. Write the name and purpose of each. The component diagram is the foundation — everything else in the review refers to it.
Free template
Free architecture review template — draw the system before you build it.
BoardSnap is an iOS app that reads whiteboard photos and produces clean summaries and action items in about ten seconds. This architecture review template structures a design review of a system or significant component — components, data flows, failure modes, and trade-offs — on a whiteboard that BoardSnap documents before a single line of infrastructure code is written.
Download on the
App Store
Free to start. Pro from $9.99/mo or $69.99/yr.
When to run this
Use this before building any new system or making significant changes to an existing one: a new service, a new data model, an external API integration, or a major refactor. Architecture reviews are expensive in time but cheap compared to rebuilding something that was designed wrong.
Budget 60–90 minutes. Bring the engineering lead proposing the architecture and at least two senior engineers with context on the systems it will interact with.
The structure
Data flows
Draw arrows between components showing how data moves through the system. Label the arrows with what data flows and in which format (REST, gRPC, event stream, etc.). Data flows reveal coupling, bottlenecks, and single points of failure that are invisible from component diagrams alone.
Failure modes
For each component: what happens when it fails? What happens when it's slow? Does the failure cascade to other components? Write the answers. Systems fail in ways their designers didn't predict — but mapping the predictable failure modes prevents the most costly ones.
Trade-offs and alternatives
Write the key design decisions made in this architecture and the alternatives that were rejected. For each decision: why was this approach chosen over the alternative? What does it give up? Documenting trade-offs is the most valuable output of an architecture review — it prevents future engineers from 'fixing' deliberate decisions.
Open questions and action items
Write every question that wasn't resolved in the review: performance under load, cost at scale, integration complexity with existing systems. For each: who will answer it, and by when? These are the action items that must be resolved before implementation begins.
How to run it
- Have the architect draw the system first
The architect draws and narrates. Reviewers don't interrupt the initial walkthrough. The first five to ten minutes are for understanding, not critique. Write questions on a sticky note and hold them until the walkthrough is complete.
- Trace data flows, not code paths
After the component walkthrough: trace three to five specific user or system flows through the diagram. 'When a user uploads a whiteboard photo, what happens?' Follow the arrow through each component. Tracing flows reveals integration gaps that component-level descriptions miss.
- Ask 'what happens when X fails?' for every component
Go through each component on the diagram: 'What happens to the rest of the system if this component goes down?' Write the answers. If the answer is 'everything fails,' that's either acceptable or a design gap — decide which.
- Surface the trade-off decisions explicitly
Ask the architect: 'What was the alternative, and why did you choose this over it?' Write the trade-off on the board. Future engineers need to know that the choice was deliberate — not a naive default.
- Write open questions before closing
Go through the board. Write every question that hasn't been answered. Assign each an owner and a resolution date. Questions that leave the room without an owner become architectural risks.
- Snap with BoardSnap
BoardSnap reads the component diagram labels, data flow annotations, failure mode analysis, trade-off decisions, and open questions. The output is a structured architecture review record — decisions documented, failure modes analyzed, and action items dated.
Why architecture reviews on a whiteboard + BoardSnap is better than digital
Architecture diagrams drawn on a whiteboard are the most collaborative format for system design — the architect can iterate in real time as reviewers raise concerns, and the diagram evolves during the review. Digital tools produce cleaner diagrams but slower collaboration.
BoardSnap preserves the whiteboard diagram and the surrounding annotations — the failure mode notes, the trade-off labels, the open questions — before anyone takes a photo and forgets to share it. The architecture record is dated and stored in the project before the meeting ends.
Frequently asked
How is an architecture review different from a code review?
A code review evaluates the implementation of a specific change. An architecture review evaluates the design of a system before implementation begins. Architecture reviews catch structural problems — wrong data model, wrong coupling, scalability issues — that would be extremely expensive to fix after code is written. Code reviews catch implementation problems within an already-accepted architecture.
Who should conduct an architecture review?
The architect or senior engineer proposing the design presents. Reviewers should include: at least one senior engineer with context on the systems being integrated, a security engineer for high-risk changes, and the engineering manager. The product manager should be present if the architecture affects product capabilities or constraints.
What should trigger an architecture review?
Any of these: a new external-facing service, a new data persistence layer, a change to authentication or authorization, a significant performance redesign, a new third-party integration, or a change that will take more than two sprints to implement. If a change would be hard to reverse, it needs a review before implementation starts.
Is BoardSnap free?
The free tier includes one project and 30 boards. Pro is $9.99/month or $69.99/year for unlimited boards and AI chat that lets you reference any architecture board in your project.
Related templates
Security review template
The security-specific gate that pairs with the architecture review for high-risk changes.
Code review checklist template
The implementation-level review that follows the architecture review.
Incident postmortem template
After an architecture-related incident, run a postmortem and update the architecture review record.
Run your next architecture review and BoardSnap will summarize it.
No exporting, no transcription. Snap the board, get the action plan.
Free · 1 project, 30 boards
Pro $9.99/mo · everything unlimited
Pro $69.99/yr · save 42%