Your monolith is 6 years old.
500k lines of code. One deploy every 3 weeks. One bad migration takes down the whole thing.
Leadership says: "rewrite it." You've seen what happens when teams do that. 18 months. Budget overruns. Half the features never make it back. The new system launches and nobody trusts it.
There's a better way. You don't rewrite — you strangle.
Here's your system:
• OrderService (monolith) handles: order creation, fulfillment, invoicing, returns
• 40 engineers. 3 teams. All deploying to the same codebase.
• Returns processing is a bottleneck. The business wants it extracted first.
• You can't freeze feature work during migration.
You need to extract Returns into a standalone service without a big-bang rewrite.
What's your migration strategy?
A) Strangler Fig — route /returns traffic to a new service via a proxy/facade, keep the monolith intact until the new service is proven. Deprecate monolith code after.
B) Branch by Abstraction — introduce an interface inside the monolith, build the new implementation behind it, flip the switch when ready, then move it out.
C) Big Bang Rewrite — freeze the monolith, rebuild everything in microservices in parallel, cut over when done.
D) Database-First Migration — extract the returns database tables into a separate schema first, build the service around it, then reroute traffic.
One of these lets you migrate live, with zero freeze periods, and with a clear rollback at every step.
Pick one — A, B, C, or D — and tell me why. Full breakdown in the comments.
Drop your answer 👇
