Service boundaries: what to get right first

The gap between knowing this and actually doing it is where most teams lose ground. If you only fix one thing about service boundaries this quarter, make it the first item below.

Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. Budget a little time for it every quarter and it never becomes a project of its own.

Start here

The wrong boundary is more expensive than no boundary. Getting it slightly wrong is survivable. Ignoring it entirely is not. If it only works because one person remembers to do something, it does not work yet.

Then this

If two services always deploy together they are one service. Small and consistent beats large and occasional here. It is the sort of thing that looks like polish right up until it costs you an enquiry.

Eventually

Data ownership is the clearest line to draw. Getting it slightly wrong is survivable. Ignoring it entirely is not. It is the sort of thing that looks like polish right up until it costs you an enquiry.

In practice

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

Worth checking on your own setup before it becomes someone else's problem to fix.