Propose a long-term strategy to decompose a monolith while maintaining API stability

WHAT THIS TESTS: Your ability to lead a multi-year architectural migration that delivers business value at every step while protecting the existing API contract and ecosystem. Interviewers want to see that you understand decomposition is a journey, not a destination, and that you can sequence work by risk, coupling, and business impact rather than technical convenience.

A GOOD ANSWER COVERS: Four things in order. First, warm up with a simple and fairly decoupled capability to validate the delivery pipeline, observability, and team topology without fighting the monolith's hardest dependencies. Second, go macro first then micro: extract large vertical slices that encapsulate a business capability and own their data, because size matters less than boundary clarity early on. Third, decouple what is important to the business and changes frequently, splitting sticky capabilities early to maximize value and minimize dependency back to the monolith. Fourth, migrate in atomic evolutionary steps where each step is a complete, deployable improvement that preserves API stability, often using a facade, strangler fig pattern, or anti-corruption layer so external consumers never feel the transition.

COMMON WRONG ANSWERS: Proposing a big-bang rewrite or freeze on monolith features while teams rebuild in parallel. Splitting by technical layer such as frontend, backend, and database rather than by business capability, which recreates the monolith as a distributed system. Ignoring data coupling and leaving the new service querying the monolith database, which fails the test of independent lifecycle and creates a hidden monolith. Suggesting microservices from day one for every domain regardless of team size or operational maturity.

LIKELY FOLLOW-UPS: How do you handle transactions that used to be local method calls across the new service boundary? What is your rollback plan if a migrated service fails under production load? How do you prevent the monolith from pulling the new service back in through shared libraries or database schemas? When do you know a service has been cut too small and needs to merge back?

ONE CONCRETE EXAMPLE: An online retail monolith tightly couples user facing, business logic, and data layers. You might start by extracting a simple pricing promotion engine because it changes frequently and is somewhat isolated. You release its data into a separate store behind a self-serve API, put a facade in front of the monolith to keep the external price endpoint stable, and deploy the new service independently. Once that macro service is stable and the team has built operational muscle, you move to high-coupling domains like inventory or checkout, repeating the atomic step pattern until the monolith shrinks to a thin routing shell.

Source: martinfowler.com