Q080: Frontend Architecture Decision Records
What Interviewers Want To Evaluate
This question tests whether you can preserve architectural context for a growing team. Interviewers want to know how you document decisions, trade-offs, rejected options, ownership, consequences, and future review points.
Senior frontend engineers make decisions that affect many people: routing strategy, state management, design-system contracts, API typing, testing standards, observability, performance budgets, and deployment rules. If those decisions are not recorded, teams repeat old debates.
Short Interview Answer
Architecture Decision Records are short documents that capture important technical decisions, context, options considered, the chosen approach, consequences, and review triggers. I would use ADRs for decisions that affect multiple teams, are expensive to reverse, or define long-term frontend standards. A good ADR is not a long essay. It is a durable record of why a decision was made so future engineers can understand, challenge, or update it with context.
Detailed Interview Answer
Frontend architecture often changes quickly. New product requirements, framework versions, performance targets, browser behavior, and team ownership can all shift. ADRs help teams remember why a decision made sense at the time.
An ADR should answer:
What decision are we making?
What context led to it?
What options did we consider?
Why did we choose this option?
What are the consequences?
What should trigger a revisit?
Who owns follow-up?
The most useful ADRs are written close to the decision. Waiting months usually produces a sanitized memory instead of real context.
When To Write An ADR
Write an ADR when the decision is cross-cutting, hard to reverse, likely to be debated again, or important for onboarding. Examples include adopting a data-fetching library, changing routing strategy, defining monorepo package boundaries, standardizing visual testing, or choosing a design token format.
Do not write ADRs for every small implementation detail. Too many records create noise and reduce trust in the process.
ADR Structure
A practical ADR can be one or two pages. The format matters less than consistency.
Useful sections include:
Status
Context
Decision
Options considered
Consequences
Migration plan
Review date or trigger
Owner
Status is important. A decision can be proposed, accepted, superseded, deprecated, or rejected.
Trade-Off Documentation
The rejected options are often the most valuable part. They prevent future teams from repeating the same debate without new evidence.
For example, if a team chooses server-driven filtering over client-only filtering, the ADR should explain scale, permissions, query cost, offline needs, and latency trade-offs.
Keeping ADRs Alive
An ADR is not permanent law. If the system changes, write a new ADR that supersedes the old one. Keep the history because it shows how the architecture evolved.
Review triggers are useful. A decision might be revisited when traffic doubles, a framework releases a stable feature, a product area is rebuilt, or performance budgets are missed.
Common Mistakes
A common mistake is writing ADRs as approval theater after the decision is already politically settled. Another is making ADRs so long that nobody reads them.
Another mistake is failing to document consequences. Every decision creates costs. If the ADR only lists benefits, it is not honest enough to guide future work.
Senior Trade-Offs
Too little documentation forces teams to rely on memory. Too much documentation slows delivery and becomes stale. The senior approach is to document decisions that carry meaningful future cost.
ADRs should support engineering judgment, not replace it.
Code or Design Example
An ADR can have a small typed template in the repo or docs system so every record captures the same essentials.
type ArchitectureDecisionRecord = {
id: string;
title: string;
status: "proposed" | "accepted" | "superseded" | "deprecated";
context: string;
decision: string;
optionsConsidered: string[];
consequences: string[];
owner: string;
reviewTrigger?: string;
};
The goal is not to render this exact type in production. The goal is to make the decision shape explicit.
Example ADR Topic
Decision: use Playwright for critical E2E flows and visual regression checks.
Context: manual regression testing is slow, teams ship UI changes frequently, and recent releases broke authenticated dashboard flows.
Consequences: CI time increases, tests need ownership, and teams must avoid fragile selectors. The benefit is stronger release confidence for high-value workflows.
Team Workflow
ADRs work best when they are easy to propose and review. A pull request can include the ADR with the implementation. For major decisions, review the ADR before implementation begins.
The ADR should live near the code or in a docs folder that engineers actually use. A hidden document outside the repo is easy to forget.
Interview Framing
In an interview, I would say ADRs are useful because architecture is a sequence of trade-offs, not a collection of perfect answers. The record helps future engineers understand what constraints existed and whether those constraints still apply.
Then I would give a concrete example from frontend architecture, such as state management, router migration, design tokens, or test strategy.
Lead Engineer Perspective
A lead engineer should encourage ADRs for high-impact choices and keep the process lightweight. The best ADR culture makes decisions easier to revisit, not harder.
Leads should also model honest trade-off writing. If every ADR claims only benefits, engineers learn not to trust them.
Revision Notes
ADRs preserve context, options, trade-offs, consequences, and review triggers for important architecture decisions.
Key Takeaways
Architecture Decision Records are a memory system for engineering teams. They reduce repeated debates and help future engineers evolve the system with context.
Follow-Up Questions
- When is an ADR worth writing?
- What should an ADR include?
- How do ADRs help migrations?
- How do you prevent stale decisions?
- Why document rejected options?
- Where should ADRs live?
- How do ADRs differ from general docs?
- What does superseding an ADR mean?
- How do ADRs help onboarding?
- How do you keep the process lightweight?
How I Would Answer This In A Real Interview
I would explain that ADRs capture decisions with context, options, trade-offs, consequences, and review triggers. I would use them for cross-team or hard-to-reverse frontend choices, keep them short, store them where engineers work, and supersede them when constraints change.