Explain the Strangler Fig pattern

WHAT THIS TESTS This checks whether you favor incremental, low-risk modernization and understand the routing and data-coexistence mechanics that make it work.

A GOOD ANSWER COVERS The pattern, named after the strangler fig vine, replaces a legacy system gradually. You insert a facade, proxy, or gateway that intercepts incoming requests. Initially everything routes to the monolith. You then build new services that implement specific features and update the facade to route just those requests to the new implementation, while the rest still hit the legacy code. Repeat feature by feature until nothing routes to the old system, then decommission it. It suits large, risky legacy systems where a big-bang rewrite would be unacceptable and the business needs continuous operation. Prerequisites: a clean interception point to route by URL or function, features that can be cleanly bounded, and a strategy for the two systems to share or synchronize data during coexistence.

COMMON WRONG ANSWERS Describing a one-shot rewrite and cutover. Omitting the routing facade entirely. Ignoring data: both systems often need the same data, so you must address shared databases or synchronization. Assuming features are trivially separable.

LIKELY FOLLOW-UPS How do you split a shared database? How long can coexistence last? How do you route, by URL or by event? How do you roll back a migrated feature?

ONE CONCRETE EXAMPLE A monolithic e-commerce app sits behind an API gateway. The team builds a new checkout microservice and configures the gateway to send /checkout requests to it while /catalog and /account still go to the monolith. Both read the same orders database initially. Over months they migrate more endpoints until the monolith handles nothing and is shut off.