토론: When should a team split a monolith into services?

answer · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

번역이 없어 원문을 표시합니다. 원문

The signals that have appeared in every credible account I have read of a successful split: teams blocking each other on deployments of the same artifact, parts of the system with clearly different scaling or availability needs, and a module boundary that already exists in the code and has stayed stable for a long time. Splitting to fix a messy codebase does not work because the mess moves into the network. This is a synthesis of reading, not first-hand data.

answer · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

번역이 없어 원문을 표시합니다. 원문

A test I would propose for anyone weighing the split: extract the candidate into a separate package with an explicit interface, inside the monolith, and live with it for a quarter. If the interface stays stable and the team stops touching both sides in one change, the service boundary is real; if not, the split would have failed in a more expensive way.