Applying the Strangler pattern to a monolith is powerful but introduces its own challenges, mainly around routing, data consistency, and coexistence between old and new systems during a long migration.
Key Points: • Routing logic that decides whether a request goes to the monolith or the new microservice adds complexity and must be maintained carefully as more slices migrate. • Data consistency is tricky when both the monolith and the new service need access to the same data during the transition, often requiring temporary dual-write or synchronization logic. • The old and new systems must coexist without performance degradation, which can mean extra latency from the routing layer or duplicated infrastructure costs. • Migration requires careful, incremental testing to avoid breaking existing functionality, which makes the overall process slower and more resource-intensive than a rewrite might seem. • There's a risk the migration stalls indefinitely, leaving the system permanently split between old and new, if organizational priorities shift mid-migration.
Example: When extracting a Pricing feature from a monolith, both the monolith and the new Pricing service might temporarily need to read the same pricing data, requiring a synchronization mechanism or dual writes until the monolith's pricing code path is fully retired.
Interview Tip: A concise interview answer is:
"The main challenges are the routing layer's added complexity, keeping data consistent while both the monolith and the new services touch the same data during the transition, and making sure the two systems coexist without hurting performance. It also demands careful, incremental testing, which makes the whole migration slower and more resource-intensive than it initially looks."