Identify the constraint
Write down the problem before splitting the application. Is a team blocked by shared releases? Does one capability dominate resource usage? Would clearer modules inside the existing application solve the same issue with less operational overhead?
Choose a bounded capability
Map data ownership, dependencies, and user-facing behavior. A candidate service should have a clear owner and a manageable interface. Avoid beginning with a deeply coupled area that requires coordinated changes across every other part of the system.
Example: extract document generation
Document rendering may have different resource needs from interactive requests. A queued job interface could let it scale independently. Before extraction, define duplicate-job behavior, retries, file storage, authorization, and how users will see completion or failure.
Plan for partial failure
Calls across services can time out while the remote operation still completes. Define idempotency where needed, consistent error behavior, and bounded retries. Trace a request across boundaries and decide which team handles each failure.
Validate one extraction before the next
Route a limited capability through the new service, observe its behavior, and keep a rollback path. Compare release effort, reliability, latency, and costs with the previous system. Additional services should be justified by evidence, not by an assumed architectural destination.