{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreih23y7vawufaieve7bwetlfasj77hdg2fdeic63o2ulpywit345se",
    "uri": "at://did:plc:5sgu76a53rz3n6unbykmovqy/app.bsky.feed.post/3m7u2pwwcblh2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreiftivptks3ubs2ejutx32o6bh7inbcgigaenmrdlg24dytzqjtmda"
    },
    "mimeType": "image/jpeg",
    "size": 101818
  },
  "description": "From the Leaning Tower of Pisa to the rainforest, the world shows us one truth: evolution beats replacement. The Strangler Fig pattern is the blueprint for evolving modern software without breaking what works.",
  "path": "/the-strangler-fig-pattern/",
  "publishedAt": "2025-12-13T07:17:23.000Z",
  "site": "https://sahilkapoor.com",
  "tags": [
    "Martin Fowler described this",
    "Why Rewrites Fail and Ugly Code Survives"
  ],
  "textContent": "The Leaning Tower of Pisa shouldn’t exist today. The real story behind why it’s still standing is the perfect setup for modern software engineering.\n\nWhen construction began in 1173, the tower started leaning by the time the third floor was built. This wasn't because medieval engineers were sloppy, but because the ground beneath one side was soft clay. The more they built, the more it tilted. By the late 1900s, the tilt reached 5.5 degrees. That’s past the point of no return. If gravity had its way, the tower was done.\n\nBut the world didn’t lose it. Instead, teams of engineers across decades pulled off something remarkable: **they stopped the lean without stopping the tower.**\n\nThey removed soil from underneath the high side, millimeter by millimeter. They anchored the base. They installed steel braces just long enough to stabilize, then removed them. They froze the structure in place and slowly coaxed it back by 40 centimeters.\n\nNot once did they shut it down and rebuild. The tower survived because every fix happened while it was still standing.\n\nPisa isn’t the only place where this logic shows up. Look at a rainforest. Nothing gets a clean reboot there, either. No tree wakes up one morning and says, “This trunk is messy, let’s start from scratch.” Life builds on top of life.\n\n**Pisa teaches you how hard systems survive. The rainforest teaches you how living systems evolve.**\n\nPut them together and you get the real insight: resilient systems don’t rebuild; they regenerate while staying alive. This is the perfect doorway into one of my favorite patterns in software: **The Strangler Fig**.\n\n### The Pattern\n\nIn nature, a strangler fig starts as a small sapling attached to a host tree. It doesn’t kill the host immediately. It wraps around it, grows stronger, forms its own trunk, and eventually, the old tree becomes irrelevant. The forest never pauses. The transformation is silent, incremental, and inevitable.\n\nThat’s exactly how modern software should replace itself.\n\nMartin Fowler described this beautifully years ago. But the magic isn’t in the metaphor; it’s in the mindset. Instead of tearing down a legacy system, you place an interception layer in front of it. You carve out small pieces, build new components around them, reroute traffic, and slowly retire the old parts.\n\nIt sounds elegant. In practice, it’s often the only path that keeps your product alive while everything around it changes.\n\n### When to use it: The moments that make founders sweat\n\nYou don’t use this approach when things are simple. You use it when touching your own codebase feels like defusing a bomb.\n\nApply this logic when:\n\n  1. **The system is live.** Uptime isn’t a technical requirement; it’s a revenue line. You can’t switch the engine off mid-flight.\n  2. **The logic is lost.** The business logic is too tangled for anyone to claim they understand everything. Engineers whisper in Slack, “Who wrote this?” and the answer is always “No idea.”\n  3. **You need speed.** You’re moving to the cloud, but a full migration would freeze feature development for months. No startup survives months of stillness.\n  4. **You are resource-constrained.** You can’t afford a parallel rewrite team. That’s a luxury for large, slow companies.\n\n\n\n### How to apply it: Reliability, Cost, and Operations\n\nHere’s how to make it work in the real world. This isn't just about writing new features; it is the ultimate form of **refactoring legacy code** —not by changing lines within a file, but by changing components within an architecture.\n\n**1. Reliability: Shrink the blast radius**\nMost founders overestimate the reliability of rewrites and underestimate the reliability of gradual transitions.\n\n  * **Start small.** Pick a reporting endpoint or a pricing rule. Never start with checkout or login.\n  * **Shadow traffic.** Before you switch users over, route 0% of real users but 100% of \"shadow\" requests. Compare the logs. Does the new service return the same data as the old one?\n  * **The 1% Toggle.** Shift 1% of traffic. Monitor. Stress test. Gradually scale to 100%.\n\n\n\n**2. Cost Optimization: Solve the problem, don't re-architect the world**\nA rewrite burns time, money, and team morale. Incremental migration burns only the parts that hurt.\n\n  * **Move CPU-heavy workloads first.** Shift them to managed cloud services. The old system remains untouched, but your infrastructure bill starts dropping immediately.\n  * **Retire expensive code paths.** Once a new slice is stable, kill the old one. That’s real cost savings with minimal risk.\n\n\n\n**3. Operational Excellence: The new system trains the team**\nTeams that adopt this pattern accidentally become better. They design cleaner interfaces because every new component must stand alone. They learn **rollback discipline** because each migration is effectively a mini-launch.\n\n### Legacy to Cloud: The Myth of the \"Big Bang\"\n\nCloud migration is where the difference between theory and reality becomes painful. In theory, you lift and shift. In reality, you lift and crash.\n\nThe giants we admire didn’t move to the cloud; they grew into it.\n\nNetflix took seven years to complete their AWS migration, from 2009 to 2016, while streaming to millions of subscribers throughout. There was no migration sprint. There was a migration strategy that outlasted most startups entirely.\n\nThey understood a fundamental truth: **Data gravity is heavy.** You cannot move a massive, entangled database to the cloud in a weekend. You have to move the application logic first, redirect the flow, and let the data follow naturally.\n\nThe \"Big Bang\" migration is a myth. A successful cloud transformation is just a thousand small, boring deployments that happened while no one was looking.\n\n### Why Builders Must Become Gardeners\n\nWe are trained to be architects. We love blueprints, clean lines, and fresh foundations. But the reality of a successful startup is much closer to a rainforest than a construction site.\n\nA rewrite is an attempt to impose order on chaos. It fails because the market  _is_ chaos. By the time you finish your perfect rewrite, the market has moved, and your new system is already obsolete.\n\nAs I wrote in Why Rewrites Fail and Ugly Code Survives, the \"ugly\" legacy code you want to delete is actually a record of every problem your business has ever solved. When you rewrite, you lose that knowledge.\n\nThe Strangler Fig pattern works because it is humble.\n\n  * It respects the code that pays the bills today.\n  * It accepts that we cannot predict the future.\n  * It allows us to change direction mid-flight.\n\n\n\nIf you are looking at your legacy codebase and dreaming of a bulldozer, stop. Look at Pisa. Look at the forest. The strongest things in the world aren't built in a day, and they aren't fixed in a day. They are nudged, grafted, and guided.\n\nDon't replace your system. Let it grow.",
  "title": "The Strangler Fig Pattern: Growing Around Legacy",
  "updatedAt": "2026-06-01T18:24:46.573Z"
}