--- title: "47/60 Days System Design Questions" url: https://daily.dev/posts/47-60-days-system-design-questions-yc3njlpdc source_url: https://daily.dev/posts/47-60-days-system-design-questions-yc3njlpdc type: freeform source: "Joud Awad" author: "Joud Awad" published: 2026-06-22T16:43:01.421Z updated: 2026-06-22T16:43:22.211Z tags: ["career", "architecture", "microservices", "monolith"] reading_time: 2 upvotes: 194 comments: 16 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # 47/60 Days System Design Questions **[Joud Awad](https://daily.dev/sources/iac4jsbu0lv8wbsc85fsh)** · [@joudawad](https://daily.dev/joudawad) · 2 min read · 194 upvotes · 16 comments ## Summary 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. ## Content 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 ## Community discussion Top comments from developers on daily.dev. **@joudawad** · 49 upvotes > **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. > > > ![ChatGPT Image Jun 22, 2026, 07_40_46 PM.png](https://media.daily.dev/image/upload/s--63fIbdVr--/f_auto/v1782146609/ugc/content_2014abec-e406-434c-b998-d13b3262b361?_a=BAMAMiWQ0) **@joudawad** · 24 upvotes > **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. **@joudawad** · 21 upvotes > **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. **@joudawad** · 15 upvotes > **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. **@dccodes** · 12 upvotes > 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 😄 > > ![GIF](https://static.klipy.com/ii/d7aec6f6f171607374b2065c836f92f4/fe/3d/NXZznjMq.gif) ## Similar posts on daily.dev - [How to Move from Monolith to a Service Based Architecture](https://daily.dev/posts/how-to-move-from-monolith-to-a-service-based-architecture-8wr0lttmy) · System Design Codex · 74 upvotes · 3 comments - [Monolith to Service Architecture](https://daily.dev/posts/monolith-to-service-architecture-2izyvqort) · System Design Codex · 102 upvotes · 4 comments - [Blog: The API-First Replatform: Why Most Modernization Projects Fail and How to Beat the Odds](https://daily.dev/posts/blog-the-api-first-replatform-why-most-modernization-projects-fail-and-how-to-beat-the-odds-xnkbvb6ch) · Wawandco · 38 upvotes · 0 comments --- Tags: [#career](https://daily.dev/tags/career), [#architecture](https://daily.dev/tags/architecture), [#microservices](https://daily.dev/tags/microservices), [#monolith](https://daily.dev/tags/monolith) [View this post on daily.dev](https://daily.dev/posts/47-60-days-system-design-questions-yc3njlpdc)