TL;DR: Strangler fig. Put a routing layer in front of the monolith, carve out one bounded context at a time behind it, and let the two run side by side while traffic shifts. The data is the hard part, not the code: use change data capture to keep both stores consistent during the overlap, and never migrate a domain and its data in one step.
How to approach it
Ask what is actually painful first, because it decides the order. Monthly releases and expensive scaling are different problems, and the first service you extract should relieve the one that hurts. Then describe a sequence with a rollback at every step, not an end state.
A strong answer
Rewrites fail because they run for two years while the monolith keeps changing, and the cutover is a single irreversible event. The strangler fig avoids both: new functionality grows around the old system until the old system is doing nothing and can be switched off.
Step one is a facade, not a service. Put an API gateway or reverse proxy in front of the monolith so every request already passes through something you control. Nothing has changed functionally, and you now have the seam that makes everything else possible. Skipping this is why migrations stall.
Step two is choosing the first extraction, and it is a judgement call worth defending. Pick a bounded context that is loosely coupled, with clear data ownership, and painful enough that success is visible. Something read-heavy with few writes is ideal because the data problem is easiest. Do not start with payments in a payments platform: the highest-risk domain is a terrible place to learn the pattern.
Step three is the data, and this is the whole difficulty. The new service needs its data, the monolith still needs it, and both are live. Change data capture (Debezium reading the database log) streams changes to the new store, so the new service can read its own data without the monolith knowing anything changed. For cutover, stop/fence the old writer, reach an agreed CDC offset and switch write authority once. Reverse CDC needs loop prevention and version ordering. A rollback after new writes must first synchronize them back and fence the new writer. Dual-write from application code is the tempting alternative and it is worse, because two writes without a transaction produce silent divergence.
Step four is moving traffic. Route a percentage of reads through the new service at the gateway and compare responses against the monolith before trusting it. Shadow traffic first, where you send the request to both and compare without using the new answer, is the cheapest way to find out you are wrong. Then shift reads, then writes, then remove the old code path.
Repeat, one context at a time.
Two things worth saying unprompted. Monthly releases are usually a pipeline and test problem rather than an architecture problem, so establishing a real CI pipeline and automated tests on the monolith often delivers most of the release-frequency benefit before any service is extracted. And every extraction converts a function call into a network call, which introduces latency, partial failure and a distributed transaction where there used to be a local one. That is a real cost, and a team that has not built the observability to see across services should build that first.
What interviewers probe next
"How long does it take?" Years for a large estate, and the honest answer is that some monoliths never fully disappear and that is acceptable. The value is delivered per extraction rather than at the end.
"How do you handle a transaction spanning old and new?" Avoid it if the boundary is drawn correctly. Where you cannot, a saga with compensating actions, and be explicit that you have traded atomicity for availability.
"What if the first extraction fails?" Before write cutover, route reads back. After accepting new-store writes, first synchronize and reconcile that state and transfer write authority safely; a gateway switch alone can lose updates.
Common mistakes
Describing the destination and skipping the sequence. Everyone can draw microservices; the question is the path.
Dual-writing from application code, which is the most common way to corrupt data during a migration.
Extracting by technical layer rather than by business domain, which produces services that must be deployed together and gives you distributed coupling instead of a monolith.