The principle, zoomed out
The single responsibility principle says a unit should have one reason to change. At small scale that unit is a class or function. At system scale the same idea applies to a service, which should own one coherent capability.
Why one reason to change matters
- When a unit serves several unrelated concerns, every concern becomes a reason to redeploy it, so changes collide and teams step on each other.
- A service with one responsibility has a clear owner, a clear interface, and a contained blast radius.
Reading responsibility by who asks
A useful test is to ask who requests changes. If billing, search, and notifications all ask the same service to change, it carries three responsibilities and should likely be split along those lines.
Pitfalls at scale
- Splitting too finely creates many tiny services with chatty network calls and no real autonomy.
- Splitting along the wrong axis, like by technical layer instead of by capability, scatters one responsibility across many services.
Align each service boundary with a single capability and a single set of stakeholders.
Key idea
Single responsibility at scale means each service owns one capability with one reason to change, aligning boundaries with the stakeholders who request changes.