Should you split the monolith at all?
Microservices solve organisational scaling problems: many teams needing to deploy independently, parts of a system with different load profiles, or components that need different technologies. They also add network calls, distributed data, versioned contracts and a far heavier operational load, so a small team often moves faster with a modular monolith. Wherever possible we write down the decision and the conditions that would make us revisit it, so the architecture can change without a dispute.
We test the decision against evidence: how often teams block each other, where deployments fail, which modules change together and which parts really need independent scaling. Sometimes the answer is to extract two or three services around clear business capabilities and leave the rest alone. Event storming sessions with domain experts often surface hidden rules and handoffs that the code never made explicit, and these shape the first boundaries.
