Service boundaries for small teams

We end up explaining this on discovery calls often enough that it deserved writing down. Most advice about service boundaries assumes a team that does not exist at your size. Here is the version that does not.

Most systems fail at the seams rather than inside any one component. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

What to keep

The wrong boundary is more expensive than no boundary. Where this goes wrong is almost never a lack of knowledge. Doing this properly once is usually cheaper than doing it approximately three times.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. The cost of getting this wrong is rarely visible on the day it happens.

Where to start

Data ownership is the clearest line to draw. Where this goes wrong is almost never a lack of knowledge. It is the sort of thing that looks like polish right up until it costs you an enquiry.

How to tell if yours is fine

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. 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

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