The Strangler pattern migrates a legacy system to microservices incrementally by routing traffic for specific functionality to new services while the old system keeps running underneath, until it can be retired.
Key Points: • Start by identifying a self-contained piece of functionality — one with clear boundaries and minimal dependencies — as the first candidate to extract. • Build that functionality as a new, independently deployable microservice rather than modifying it in place inside the monolith. • Introduce a facade or proxy layer (often an API Gateway) in front of both systems that routes requests for the migrated functionality to the new service and everything else to the legacy system. • Repeat the process feature by feature, gradually shrinking the monolith's responsibilities as more traffic shifts to new services. • Once the legacy system handles no remaining traffic, it can be safely decommissioned, having been "strangled" over time rather than replaced in one risky cutover.
Example: A legacy insurance platform might extract "policy quoting" first since it has few dependencies on the rest of the system, route quote requests through a gateway to the new microservice, and leave claims processing on the monolith until it's migrated in a later phase.
Interview Tip: A concise interview answer is:
"I'd pick one well-bounded piece of functionality, rebuild it as a standalone microservice, and put a facade or gateway in front of both systems that routes requests for that functionality to the new service while everything else still goes to the monolith. Repeating this feature by feature minimizes risk versus a big-bang rewrite, and the legacy system is decommissioned only once nothing routes to it anymore."