Splitting a .NET monolith
The big rewrite never comes. A method to carve out one service at a time, in production, without freezing the roadmap.
Published on · 1 min read
All notesNobody can freeze a product for a year to rewrite it. Splitting a monolith means carving out one service at a time, in production, while the team keeps shipping.
Start with boundaries, not code
Before creating a project I look for business boundaries: the places where the vocabulary changes. "Customer" does not mean the same thing to billing and to support. Each boundary is a candidate.
Pick the first service to learn, not to impress
The first service should be loosely coupled, useful and reversible. It is where everything the next ones need gets set up: pipeline, observability, secret management, API contract, event publishing.
Strangle, don't replace
A gateway (API Management or YARP) sits in front of the monolith. Calls to the extracted feature go to the new service; everything else still goes to the monolith. Routes switch one by one, and each switch can be undone.
Separate the data logically first
The new service owns its tables, even if they stay in the same database for a while. The monolith no longer writes to them directly: it goes through the API or an event. Physical separation comes later, without risk.
Events to undo the joins
Where the monolith joined two domains, the service publishes an event ("order confirmed") that the other domain consumes to keep its own copy. Service Bus does this job very well.
Measure before, measure after
Response time, error rate, deployment frequency: measure them before you start. Without a starting point there is no way to say whether the split helped.