2025-02-14 · Min-jun Park

When to Split a Service: A Boundary Checklist

Teams often split services because deploy queues feel slow, not because boundaries are wrong. That creates integration tax without delivery gains.

We use a boundary checklist before any split proposal: independent release cadence, distinct failure domains, separate scaling profiles, clear data ownership, and a team that can own on-call. Missing two or more means the split is premature.

False positives include "two teams touch the code" and "the file is large." Size and contributor count are weak signals compared to change coupling in your version history.

In cohort labs, participants run the checklist against a real module from their org. Most find one candidate worth deferring and one worth accelerating with better contracts instead of a split.

#boundaries #system design