Service boundaries: the questions we get asked most

The gap between knowing this and actually doing it is where most teams lose ground. The questions about service boundaries that come up most often on our calls.

Most systems fail at the seams rather than inside any one component. It is the sort of thing that looks like polish right up until it costs you an enquiry.

Do we need to care about this?

The wrong boundary is more expensive than no boundary. None of that requires a large budget, only a decision and someone to own it. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. That sounds obvious written down. It is still the thing most often skipped.

How do we know it is working?

Data ownership is the clearest line to draw. There is a version of this that is over-engineered, and it is worth avoiding. Write the reasoning down alongside the decision, because the reasoning is what changes first.

How to tell if yours is fine

Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. 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

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.