What is software architecture?
“Define software architecture in your own words. What is in it, what is not, and how would you tell whether a system has good architecture?”
What this tests
- Whether the candidate sees architecture as a set of decisions, not a diagram
- Understanding of components, boundaries, dependencies and failure domains
- Ability to connect structure to a measurable quality (change cost, availability, latency)
- Whether "good" is defined relative to requirements or as an absolute
Answers by level
Read the beginner answer first and notice what is missing.
Architecture is the set of decisions that are expensive to change later: where the boundaries are, which component owns which data, how components communicate (in-process call, HTTP, queue), and where the system is allowed to fail independently. The boxes on the diagram are the visible result; the decisions are the architecture.
Concretely I look for components with a single responsibility, interfaces that hide internals, dependencies that point in one direction, and failure domains that are deliberate — if the recommendations service dies, checkout should still work. Data flow and deployment shape (one process vs many) are part of it too.
Good is relative. A system is well architected when its structure matches its actual requirements: the measured load, the team that maintains it, and the changes it needs to absorb. A three-person team with 50 requests per second does not need the architecture of a payments network.
Green flags · Red flags
- Defines architecture as decisions with high change cost, not a picture
- Names boundaries, dependencies, data ownership and failure domains
- Ties "good" to measured requirements and team shape
- Distinguishes code structure from application and system architecture
- Gives a concrete example of a bad boundary (one change touching many parts)
- "Good architecture is scalable and modular." — adjectives with no requirement attached
- Equates architecture with the technology list (React, Kubernetes, Kafka)
- Treats the diagram as a target picture drawn before any problem exists
- Cannot say what breaks when a named component fails