Service boundaries, explained without the jargon

The advice here is unglamorous, which is probably why it gets skipped. Here is service boundaries without the vocabulary that usually surrounds it.

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. Check it against what you would want a competitor's site to get wrong.

The short version

The wrong boundary is more expensive than no boundary. It is worth being explicit about, because assumptions differ quietly. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. In practice this is a scheduling problem more than a technical one.

If two services always deploy together they are one service. The cost of getting this wrong is rarely visible on the day it happens. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Where to go from here

Data ownership is the clearest line to draw. There is a version of this that is over-engineered, and it is worth avoiding. Doing this properly once is usually cheaper than doing it approximately three times.

What this looks like day to day

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
• If two services always deploy together they are one service — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If any of that sounds like a description of your current setup, it is fixable.