The real cost of ignoring service boundaries
The version of this that works is simpler than the version most people imagine. Nobody bills you for neglecting service boundaries. The cost shows up somewhere else.
The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.
Where the cost lands
- Time spent on work that should not have been necessary
- Enquiries that quietly never arrive
- The wrong boundary is more expensive than no boundary
- Rework, once the problem is finally visible
If two services always deploy together they are one service. None of that requires a large budget, only a decision and someone to own it. It is worth deciding this deliberately rather than inheriting whatever the last person set up.
A reasonable first step
Data ownership is the clearest line to draw. It is worth being explicit about, because assumptions differ quietly. Write the reasoning down alongside the decision, because the reasoning is what changes first.
How to tell if yours is fine
Most systems fail at the seams rather than inside any one component. Three things worth confirming about service boundaries before you move on:
- Someone can say what the current setup is without going to look
- The wrong boundary is more expensive than no boundary — and you know whether that is true here
- There is a way to tell whether the last change to this helped
If you are not sure where your systems currently stand on this, it takes us about an hour to find out.