Build fluency in the vocabulary of migrating a legacy monolith feature by feature behind a facade instead of a big-bang rewrite.
0 / 5 completed
1 / 5
A teammate explains that a legacy monolith is migrated by routing individual features to a new service one at a time behind a facade, leaving the rest of the traffic on the old system until every feature has been moved and the monolith can finally be retired. What migration pattern is being described?
The strangler fig pattern is exactly this: a facade routes traffic for individual features to a new service one at a time, while every not-yet-migrated feature continues being served by the old monolith, so the new system gradually takes over, feature by feature, until the monolith can finally be retired, named after the strangler fig vine that gradually envelops and eventually replaces its host tree. A DNS zone transfer is an unrelated concept about replicating name server records. This gradual-feature-by-feature-replacement approach is exactly why the strangler fig pattern is favored over rewriting a legacy monolith all at once.
2 / 5
During a design review, the team adopts the strangler fig pattern to migrate a legacy monolith, specifically so each migrated feature can be validated in production before the next feature is touched, rather than betting the whole migration on one big-bang cutover. Which capability does this provide?
The strangler fig pattern here provides incremental, low-risk migration with continuous validation, since each feature is proven in production behind the facade before the next feature is migrated, so a problem in one migrated feature never risks the entire system at once. Rewriting and cutting over the entire monolith in one release bets the whole migration's success on a single, high-stakes cutover event. This one-feature-at-a-time-with-validation behavior is exactly why the strangler fig pattern is favored for migrating large, high-risk legacy systems.
3 / 5
In a code review, a dev notices a migration plan proposes rewriting the entire legacy monolith and cutting every feature over to the new system in one single release, instead of routing features to the new service incrementally behind a facade as the strangler fig pattern would suggest. What does this represent?
This is a missed strangler-fig-pattern opportunity, since incremental feature-by-feature migration behind a facade would validate each piece in production instead of betting everything on one big-bang cutover. A cache eviction policy is an unrelated concept about discarded cache entries. This one-release-cut-everything-over pattern is exactly the kind of high-risk migration a reviewer flags once a large, high-stakes legacy system is involved.
4 / 5
An incident report shows a big-bang cutover of an entire legacy monolith to a new system caused a multi-day outage, because dozens of untested feature interactions in the new system only surfaced once every feature went live simultaneously. What practice would prevent this?
Adopting the strangler fig pattern to migrate and validate features one at a time behind a facade lets untested interactions surface on a small scale instead of all at once. Continuing to plan big-bang cutovers of the entire monolith regardless of how many multi-day outages that approach has caused before is exactly what caused the outage described in this incident. This incremental-feature-migration approach is the standard fix once big-bang cutovers are confirmed to cause large-scale outages.
5 / 5
During a PR review, a teammate asks why the team reaches for the strangler fig pattern instead of simply rewriting the monolith from scratch and cutting over once everything is ready, given that a single rewrite avoids running two systems side by side for months. What is the reasoning?
The strangler fig pattern trades the operational overhead of running the facade and both systems side by side for a much smaller blast radius per migrated feature, while a single full rewrite avoids that dual-running overhead but risks a large-scale failure the moment everything cuts over at once. This is exactly why the strangler fig pattern is favored for migrating large, high-risk legacy systems, while a single full rewrite remains viable only for small systems where a big-bang cutover carries acceptable risk.