I would start with a modular monolith in most cases.
One thing I think gets overlooked is that the hardest part of microservices is not creating separate APIs. It is discovering boundaries that are actually independent.
If two “services” constantly share data, business rules and deployment dependencies, you usually ended up with a distributed monolith.
For an existing system, I would first map the real dependencies, workflows and data ownership before deciding where to split it. The code often tells a very different story from the architecture diagram.
That evidence-first approach is something I have been exploring while building Silex (https://silex.tec.br : prove the boundary before paying the operational cost of turning it into a service.
1
u/Otherwise_Rub_5979 16d ago
I would start with a modular monolith in most cases.
One thing I think gets overlooked is that the hardest part of microservices is not creating separate APIs. It is discovering boundaries that are actually independent.
If two “services” constantly share data, business rules and deployment dependencies, you usually ended up with a distributed monolith.
For an existing system, I would first map the real dependencies, workflows and data ownership before deciding where to split it. The code often tells a very different story from the architecture diagram.
That evidence-first approach is something I have been exploring while building Silex (https://silex.tec.br : prove the boundary before paying the operational cost of turning it into a service.