Separation of Concerns
Organising so that a change to one concern touches one place.
4 to work through
-
beginner Multiple choice
A user signup request takes 4 seconds at p99. Tracing shows the handler sends a welcome email through a third-party API and writes to a CRM before returning. What is wrong architecturally?
2 min answer -
intermediate
A ride-hailing company moving off its monolith found engineers actively avoiding service calls because they could not see the latency or the failures those calls produced. Lyft's published answer was Envoy, open-sourced in September 2016: a separate process on every host that all service traffic flows through. Which concern was actually separated, what did the separation cost, and when is a shared library the better answer?
3 min answer -
advanced
An AI inference platform handles authentication, quota accounting, prompt assembly, safety filtering, model invocation, token counting, billing emission and response streaming in one request handler. Latency is currently fine. Argue for or against separating these concerns, and identify which separations pay for themselves first.
2 min answer -
advanced
An issue tracker with local-first behaviour keeps a client-side store, a sync engine, and a server. A product manager asks for a new field on an issue. In a well-separated design, how many places should change, and what does the answer tell you?
1 min answer
3 terms in this topic
Concern Restatement Tax
The fixed, permanent cost paid by every feature when architectural layers restate the same concern at several altitudes instead of separating differe…
conceptCross-Cutting Concern
A responsibility that legitimately appears throughout a system rather than in one module, such as logging, authorisation, tracing or transaction mana…
conceptSeparation of Concerns
Organising a system so that one kind of change touches one place, and so that different concerns can fail and scale independently.
Neighbouring topics
Architecture Fundamentals
General material on what solution architecture is and what an architect is accountable for.
Requirements to Constraints
Turning stated requirements into the constraints that actually bound a design.
Functional vs Non-Functional
Behaviour versus quality of behaviour, and why only the second constrains structure.
Architectural Drivers
The small subset of requirements whose change would force the structure to change.
Quality Attributes
Availability, latency, throughput, security, cost — expressed as testable scenarios.
Architecture Principles
Durable agreed rules that rule options out, stated with rationale and implications.
Coupling
How much one component must know about, or change alongside, another.
Cohesion
Whether the things inside a boundary belong together and change for the same reason.
Modularity
Composing a system from parts that can be understood and replaced independently.
Abstraction & Encapsulation
Hiding mechanism behind contract, and protecting invariants by owning state.
Architecture Styles
System-level organising shapes, and how they differ from problem-level patterns.
Evolutionary Architecture
Designing for guided incremental change rather than for correctness on day one.
Fitness Functions
Automated checks that an architectural characteristic still holds.
Architecture Documentation
What to write down, at what altitude, and what nobody will ever read.
Conway's Law
Systems mirroring the communication structure of the organisation that builds them.
Trade-off Fundamentals
Why every architecture is a set of purchases, and how to state what you gave up.
Technical Constraints
Existing estate, skills, licences and platforms as inputs rather than obstacles.
Architecture Roles
Solution, enterprise, domain and platform architecture, and where each is accountable.
Reference Models
Shared conceptual frames — layering, tiers, viewpoints — and their limits.