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 👇
Top comments (7)
A is right i think
B is wrong because it is a strategy that might be used inside the strangler pattern
C is obvious no, because the code base is too large.
D, i didn't know thanks for the information 😄
there should be a cross platform mega like for your comments!
Apprichitate your support mate thank you so much
Why B is close but different (Branch by Abstraction):
Real pattern — but it lives inside the codebase. You wrap the logic behind an interface, build the new implementation behind a flag, then flip it. It's a refactoring tool, not a deployment strategy. Often used inside a Strangler Fig migration to prepare internal structure. But on its own it doesn't get you to an independently deployed service.
Why C is wrong (Big Bang Rewrite):
The monolith doesn't freeze while you rebuild. Business keeps shipping features. Your parallel rewrite immediately diverges from reality. "Done" keeps moving. The cutover is a single high-stakes event with no incremental validation. Joel Spolsky called this "the single worst strategic mistake any software company can make" — because every hack in the old codebase was a real bug fix you've now forgotten.
Why A wins:
You introduce a routing proxy in front of the monolith. /returns traffic routes to the new service. The monolith handles everything else. You run both in parallel — no freeze, no big-bang. Migrate one endpoint at a time, each step independently rollback-able. Only deprecate monolith code after the new service has proven itself under real load. Netflix and Amazon have run versions of this at scale.
Why D is more dangerous than it looks (Database-First):
Extracting the DB tables first sounds logical but breaks the monolith's ORM immediately. You've created a distributed data problem before building the distributed system to handle it. Data migration is the last step — extract service logic first, keep data co-located temporarily, then migrate with dual-write. Doing it in reverse order compounds the risk at every step.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.