Why service boundaries matters more than it looks

Every audit we run turns up some version of this. Service boundaries is easy to treat as a detail, and that is exactly why it is worth a few minutes of attention.

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.

What it costs to ignore

The wrong boundary is more expensive than no boundary. The cost of getting this wrong is rarely visible on the day it happens. Write the reasoning down alongside the decision, because the reasoning is what changes first.

If two services always deploy together they are one service. Where this goes wrong is almost never a lack of knowledge. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

Where it usually goes wrong

Data ownership is the clearest line to draw. Getting it slightly wrong is survivable. Ignoring it entirely is not. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

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.