A dependency diagram can make one module look easy to extract. The work becomes harder when both sides still write the same tables or multiple teams must coordinate every release. The coupling that matters often sits in data and operating responsibilities rather than imports.
Name the problem the split should solve
Deployment conflict, scaling, fault isolation and team ownership point to different boundaries. Without a measurable problem, service count becomes the only visible progress metric.
Use a boundary one team can own
Map the decisions, data and on-call responsibility that belong together. A service too small for one team to understand and operate independently creates coordination instead of removing it.
Separate write authority
A new API with shared table writes is still tightly coupled. Start by restricting ownership through schemas and accounts, then move physical storage when it creates operational value.
Choose a reversible first extraction
Avoid both the most critical domain and a trivial utility. Select a meaningful path with observable benefit, known dependencies and a route back. Measure the original problem again after release.