A practical checklist for service boundaries

Teams tend to reach for this after something has already gone wrong. Run through this the next time service boundaries comes up.

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. If it only works because one person remembers to do something, it does not work yet.

The checklist

• The wrong boundary is more expensive than no boundary
• If two services always deploy together they are one service
• Data ownership is the clearest line to draw
• Someone is named as the owner
• There is a date to review it again

What is actually at stake

The wrong boundary is more expensive than no boundary. Small and consistent beats large and occasional here. Budget a little time for it every quarter and it never becomes a project of its own.

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
• Data ownership is the clearest line to draw — 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.