A 15-year-old monolith runs the core of the business. Leadership wants microservices. How do you approach it, and what would make you refuse?

What the interviewer is testing

Whether you start from the business problem or from the target architecture, and whether you are willing to say no.

First, establish the actual problem

"Microservices" is a solution. What is the pain?

• Releases are slow and risky → the fix may be a deployment pipeline and test suite, not a distributed system.
• One component cannot scale → extract that one component. That is not a microservices programme.
• Teams block each other → module boundaries with enforced ownership may be enough.
• Nobody understands the code → decomposition will not create understanding; it will distribute the confusion across a network.
• We cannot hire people to work on it → a real problem, and one of the few that argues for rewriting.

Roughly half of "we need microservices" requests are better served by a modular monolith, a deployment pipeline, or extracting two components.

If decomposition is genuinely warranted

Strangler fig, never big-bang rewrite. Put a facade in front — a proxy or gateway — routing everything to the monolith initially. Extract one capability at a time, re-point its route, verify, repeat.

Sequence by value and risk, not by ease. The first extraction should be something with a clear boundary, real pain, and low blast radius — it is as much a proof of the process as of the architecture. Do not start with the hardest thing, and do not start with something so trivial that it proves nothing.

Data is the hard part. The monolith almost certainly has one database with joins across every domain. Extracting a service means untangling those joins, which means deciding what each service owns and replacing joins with API calls or replicated read models. This is 70% of the work and is budgeted at 20% in most plans.

Anti-corruption layer at each boundary, so the monolith's model does not become the new services' model.

Set the end condition. Which capabilities will be extracted, and which will remain in the monolith forever? A modernisation without a defined end runs until funding stops, leaving both architectures and the integration between them.

What would make me refuse

• No test coverage and no appetite to build it. Decomposition without tests is undirected change to a system nobody can verify.
• A hard deadline coinciding with a major business event. Modernisation and a peak season do not share a quarter.
• No product ownership of the domains. If nobody can say what a capability's boundary is, the services will be drawn along technical lines and will not be independent.
• The real driver is a résumé or a vendor. Says itself.
• The monolith is stable, well-understood and rarely changed. Then it is not a problem, it is an asset, and the money is better spent elsewhere.

What a strong answer adds

Proposing a modular monolith as the first phase regardless of the destination: enforce boundaries inside the existing codebase, prove they are right by observing what actually changes together, and only then extract. It de-risks the expensive decision and delivers most of the team-autonomy benefit early.