Originally coined by Martin Fowler in the early 2000s, the "Strangler Pattern" is a software pattern that can be applied in situations where a legacy system has become difficult to maintain, but still provides important business value. It may be too risky or expensive (in terms of time or money or both) to rewrite and replace the system wholesale. Instead, following the strangler pattern involves building around the existing system, gradually supplanting it, usurping its features with newly-written code or third-party utilities before eventually choking the life out of the old system like the strangler fig from which this pattern takes its name.
To take a concrete example, if we imagine a large monolithic system for running an e-commerce store, it might include features like a customer database, complex pricing models for setting the cost of products, the ability to track inventory, send order confirmation emails, and process credit card payments. Over the course of months or years, developers applying the strangler pattern to this system could migrate the customer database to some standard Customer Relationship Management (CRM) tool, build an API to expose the pricing models for consumption by other systems, adapt the inventory tracking to be only a thin shim layer over data provided by the warehouse or shipping contractor, replace the native email functionality with calls to a transactional email API offered by a third-party vendor, and swap the credit card processing features for a separate external vendor. Eventually, the old system would be winnowed down to only the pricing models and perhaps some orchestration glue code coordinating activity between third-party vendors.
The result of successful application of the strangler pattern is software small enough to drown in a bathtub. Depending on operational constraints, the rump system that remains can either be left in place or in the end finally replaced and retired completely.