Splitting Part of a Monolith Into Services

The first service we separated from a large application solved a real problem. It also gave us a new API to version, another deployment to monitor, and a network call that could fail. That trade-off shaped the modernization work I participated in at Softcraft. The existing system had real problems. Deployments carried unrelated changes, modules were coupled, and understanding the effect of a feature often required too much context. Separating responsibilities helped. Teams could work on some areas more independently, and changes no longer required deploying the entire application every time. The complexity didn’t disappear. Part of it moved from the codebase to communication, data ownership and operations.

From a Method Call to a Network Call

Inside the monolith, one part of the application could call another in the same process. The call was fast, and a shared transaction could keep related changes together. After separation, that interaction crossed a network. Now the other service could be unavailable. The request could time out even if the work completed. Contracts needed versioning. Authentication had to work between services. Logs from one operation were spread across applications. For some boundaries, these costs were worth it. We just needed to include them in the decision. Calling the architecture “microservices” didn’t solve them. We needed explicit decisions about retries, ownership, observability, and what should happen when only part of a workflow succeeded.

Data Ownership

The monolith made it easy for different modules to read the same tables. That convenience also created coupling. A change that looked local could break a query in another part of the system. Service boundaries forced us to discuss which capability owned the data and how other parts of the platform should access it. Those conversations improved the architecture because responsibilities became visible. They also introduced distributed consistency. Not every workflow could rely on one database transaction anymore. Some information would be updated later, and the system needed to represent that state honestly. The ownership became clearer, but the consistency between systems became more complex.

Independent Deployments

A service isn’t independent simply because it has its own repository. It needs a repeatable build, deployment, configuration, monitoring, and recovery process. If every service requires manual coordination or a different operational approach, the organization has created more deployment units without creating independence. Our modernization work was connected to improvements in CI/CD, containerization, automated testing, and observability. Without that foundation, additional services would have multiplied operational friction. That’s why I don’t see microservices as a starting objective. The team needs to be able to operate the architecture we design. Some parts of the application benefited from separation because they had clear responsibilities, different scaling needs, or integration workloads that needed independent processing. Other parts were better kept together. Not every module needed to become a service. A good internal boundary could improve maintainability without adding a network call, another deployment, and another production surface.

We never made one “monolith or microservices” decision for the whole platform. Some responsibilities became services because the team needed independent delivery or processing. Others stayed as modules because a network boundary didn’t give us enough in return. The final picture was less consistent than a diagram where every box followed the same rule, but it reflected the problems we had. It also left us with fewer deployments and failure paths than separating everything would have created.