Revisiting the Strangler Pattern: How to Carve Monoliths with Precision

When faced with a monolith, many teams reach for microservices as the escape hatch. But a rewrite is rarely the answer. In fact, I’d argue it’s often the most expensive and risky route. A better alternative—and one I’ve used successfully time and again—is the strangler pattern.

The idea behind the strangler pattern is elegant in its simplicity: instead of tearing the monolith down in one go, you incrementally replace it. You wrap the existing system, gradually routing requests to new, modular services. Over time, the monolith shrinks as its responsibilities are replaced.

My first hands-on use of this pattern was at Lyons Davidson Solicitors. We were working with a tangled VB6 and Silverlight system, and it was clear a full rewrite wasn’t viable. Instead, I focused on identifying domain boundaries. By introducing MVC and shared frameworks around those boundaries, we began to isolate functionality in a way that allowed us to replace pieces incrementally.

Later, at SpaSpace, the strangler pattern became an architectural mainstay. With domain-driven design as our compass, we started by carving out services that matched bounded contexts—like authentication, bookings, or notifications. Instead of abstracting everything up front, we applied CQRS principles and leveraged dependency injection to swap out interface implementations of services and repositories. This allowed us to validate SOLID principles in practice and achieve progressive strangulation of the monolith without disrupting dependent logic.

We’d intercept calls at integration points—APIs, message queues, or even direct database access—and redirect them to the new implementations. This allowed teams to build, test, and deploy microservices in parallel without disrupting existing behaviour. In some critical paths, we retained the existing concrete implementations as fallbacks, enabling the system to gracefully recover by reverting to the monolith logic if the new execution paths encountered errors.

The real power of the strangler pattern lies in its flexibility. You can move as fast or as slow as the business allows. You gain confidence with every piece that’s replaced. And perhaps most importantly, you avoid the trap of chasing a mythical “big bang” migration—a mindset more aligned with traditional Waterfall delivery than Agile iteration. The strangler pattern, in contrast, exemplifies Agile thinking: delivering incremental value, validating progress continuously, and allowing for course correction without derailing the entire transformation.

If you’re considering moving away from a monolith, my advice is simple: don’t rush it. Invest in understanding your domains, establish boundaries with care, and strangle your monolith with precision. The result won’t just be a modern architecture—it’ll be a resilient, adaptable system that grows with your business. While this approach may take more time and upfront investment, it pays dividends in the long run. Too often, businesses focus solely on short-term gains or speed to market, neglecting the strategic advantage of building for maintainability, scalability, and change. Done right, this investment leads to fewer costly rewrites, smoother scaling, and better alignment with future business needs.