Build fluency in the vocabulary of gradually migrating a legacy monolith to a new system.
0 / 5 completed
1 / 5
At standup, a dev mentions gradually routing an increasing share of traffic from a legacy monolith to a new service, one capability at a time, until the legacy system can finally be retired. What is this migration pattern called?
The strangler fig pattern gradually routes an increasing share of traffic from a legacy monolith to a new service, one capability at a time, until the legacy system can finally be retired once nothing depends on it anymore. A single, all-at-once cutover replacing the entire legacy system risks a much larger, riskier failure if something goes wrong during that one migration event. This gradual, capability-by-capability approach is what makes a large legacy migration manageable and reversible at each step.
2 / 5
During a design review, the team wants a routing layer in front of both the legacy monolith and the new service, directing each request to whichever one currently owns that specific capability. Which capability supports this?
A routing facade sits in front of both the legacy monolith and the new service, directing each request to whichever system currently owns that specific capability, without the calling client needing to know which one that is. Requiring every client to track ownership directly couples that client to an internal migration detail that's actively changing. This routing facade is what lets a migration proceed incrementally without breaking every existing client along the way.
3 / 5
In a code review, a dev notices the team keeps the legacy monolith's code for an already-migrated capability intact but unreachable, rather than deleting it immediately once traffic is routed elsewhere. What does this represent?
A rollback safety window keeps a migrated capability's legacy code intact but unreachable for a period, so the routing facade can quickly fall back to it if the new service reveals an unexpected problem. Deleting the legacy code immediately removes that safety net the moment it might still be needed. This temporary retention is what makes each incremental migration step genuinely reversible rather than a one-way, high-stakes commitment.
4 / 5
An incident report shows a newly migrated capability had a serious bug in production, but the team couldn't roll back quickly because the corresponding legacy code had already been deleted right after the traffic cutover. What practice would prevent this?
Keeping a migrated capability's legacy code available for a defined rollback window before deleting it preserves the ability to quickly fall back if a serious bug surfaces in production. Deleting it immediately upon cutover removes that safety net right when it might still be needed. This rollback-window discipline is a core part of what makes the strangler fig pattern's incremental approach actually safe in practice.
5 / 5
During a PR review, a teammate asks why the team migrates a legacy monolith gradually, capability by capability, instead of a single, all-at-once cutover to the new system. What is the reasoning?
A gradual, incremental migration limits the blast radius of a problem to just one recently migrated capability at a time, since the rest of the system is unaffected. An all-at-once cutover risks a much larger, harder-to-diagnose failure across the entire system simultaneously. The tradeoff is that a gradual migration takes considerably longer to fully complete and requires maintaining a routing facade throughout that entire process.