“Architecture” and “design” get used interchangeably — but they're not the same. Knowing which one you're facing tells you how hard to think, how many people to involve, and how much time a decision deserves.
Definitions
What is software architecture?
There's no single definition — but the popular ones converge on the same idea. Tap through four takes and watch them build toward one:
Apply it
Frontend architecture
Take that fourth definition and swap “system” for “frontend” — it still holds. Frontend architecture is the set of significant design decisions about how the frontend is organized to achieve its goals (performance, maintainability, and so on). It's system design with the spotlight on the client side.
The distinction
The spectrum: architecture ↔ design
Picture every decision on a line. Architecture sits on the left (bigger, harder), design on the right (smaller, easier). Drag the handle — the four attributes morph as you move:
Architectureleaning 84% — drag the handle
Closest example: Micro-frontends vs monolith
ArchitectureDesign
High-levelAltitudeLow-level
Hard to changeReversibilityEasy to change
StrategicPlanningTactical
What & whereFocusHow
Sort it out
Architecture or design?
Run real decisions through those attributes. For each, ask: high or low-level? Hard or easy to change? Many people or few?
0/6 sorted
Migrating the app from React to Vue
Where a single component keeps its data (local state vs store)
Micro-frontends vs a monolith
Naming a component's prop
Adopting SSR across the entire app
Debouncing a search input
Tip
One caveat: a design-level choice can become architectural when it ripples everywhere — e.g. the API of a shared component library that every team depends on. Scope is what tips the balance.
The payoff
Why this matters
Naming the side a decision sits on protects you from the two mistakes almost every team makes:
The practical rule
Knowing whether a decision is architecture or design tells you how much time to invest. Architecture: slow down, get it right, align people. Design: decide fast, move on, refine later.
Practice
Check your understanding
Q1Sort each scenario
Architecture or design decision?
Choosing the app's state-management library
Adding a 'ghost' variant to one button
How the app splits into modules and their boundaries
How a date is formatted in one widget
Q2Multiple choice
Which attribute most clearly marks a decision as architectural?
Q3Multiple choice
You've identified a decision as a design (not architecture) decision. The practical implication?
Reflect
Audit a recent debate
Think of a decision your team recently spent time on. Place it on the spectrum using the four attributes. If it was design but ate hours of debate, that's over-engineering. If it was architecture but got waved through quickly, that's a risk worth revisiting.
Key takeaways
→Architecture = the significant decisions that shape the system's structure to hit its quality attributes.
→Architecture is high-level, hard to change, strategic, and about what/where; design is low-level, easy to change, tactical, and about how.
→Scope can promote a design decision to architectural (e.g. a shared component library).
→Naming the side tells you how much time to invest — don't under-estimate architecture or over-engineer design.