Big-bang rewrites rarely finish. The strangler fig pattern keeps the monolith running while new capabilities grow at the edges, routed through a thin facade (API gateway, reverse proxy, or feature router) that can send traffic to legacy or modern implementations.
Start with a seam that is already logically isolated—reporting, notifications, pricing—even if the code still lives in one repo. Extract behind an interface the monolith calls synchronously, then move callers to HTTP or async events once the new service proves stable.
Data is the hard part. Prefer read replicas and change-data-capture for read-heavy slices; for writes, design compensating transactions and idempotency keys early. Dual-write phases are risky—keep them short and instrumented.
Keep deployment cadence: each extraction should be shippable behind flags. Dark launch new paths, compare latency and error budgets, then shift percentage traffic gradually.
Team topology follows: a vertical slice team owns the extracted service end to end while the monolith team maintains compatibility shims until cutover. Shared coding standards and observability reduce integration surprises.
Know when to stop strangling: not every module deserves a service. Sometimes modular monolith boundaries plus clear ownership are enough until load or org scale demands finer separation.
Related: DevOps consulting, case studies, and resources.