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 👇
#30DaysOfSystemDesign #SystemDesign #Microservices #SoftwareArchitecture #BackendEngineering

Smiley Face

Joud Awad

A system design scenario presents a 6-year-old monolith with 500k lines of code and asks how to extract a Returns service without a big-bang rewrite. Four migration strategies are offered: Strangler Fig (proxy-based traffic routing), Branch by Abstraction (interface-driven internal swap), Big Bang Rewrite (parallel rebuild), and Database-First Migration (schema extraction first). The post frames the Strangler Fig pattern as the approach enabling live migration with zero freeze periods and rollback at every step.

47/60 Days System Design Questions

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.
<img src="https://media.daily.dev/image/upload/s--63fIbdVr--/f_auto/v1782146609/ugc/content_2014abec-e406-434c-b998-d13b3262b361?_a=BAMAMiWQ0" alt="ChatGPT Image Jun 22, 2026, 07_40_46 PM.png">

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 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.

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 😄
<img src="https://static.klipy.com/ii/d7aec6f6f171607374b2065c836f92f4/fe/3d/NXZznjMq.gif" alt="GIF">