Five mistakes teams make with service boundaries

Most teams know this matters. Fewer have decided who owns it. These are the ones we run into repeatedly when we audit service boundaries.

Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. It rarely shows up as a line item, which is exactly why it slips.

Warning signs

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• The wrong boundary is more expensive than no boundary
• If two services always deploy together they are one service
• Never checking whether the fix actually worked

Data ownership is the clearest line to draw. Small and consistent beats large and occasional here. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

What to do next

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
• 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

Most of the value here comes from doing the first two things, not all of them.