Propose a long-term strategy to decompose a monolith while maintaining API stability
This tests strategic prioritization and incremental migration without ecosystem breakage. Start with simple decoupled capability, go macro first then micro, split vertically by domain owning data, and use atomic steps with facades to preserve APIs.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
When beginning a multi-year monolith decomposition, which capability should be extracted first to validate delivery and operational practices without taking on the monolith's riskiest dependencies?
- a.A horizontal technical layer such as the shared data access tier
- b.A simple, fairly decoupled capability used to validate the delivery pipeline and team topologyCorrect
- c.The highest-traffic checkout flow to prove the architecture under production load
- d.The business domain that changes most frequently and drives the highest value
Why? this is the answer
The strategy explicitly begins with a low-risk, decoupled warm-up extraction to validate the pipeline and observability before fighting the monolith's hardest dependencies. Choosing the highest-value, fastest-changing domain is tempting, but that is a later priority after the team has built operational muscle through a safer initial extraction.
Just read this? Test yourself on what you have been reading.
Read the original → martinfowler.com
- #microservices
- #monolith decomposition
- #api stability
- #evolutionary architecture
- #platform strategy
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on microservices — each one lists the topics its interview covers.
See open roles