The Strangler Fig Pattern in Practice — Makokha Mark Kitts

The Problem with Big-Bang Migrations

Big-bang migrations fail. You rewrite everything, deploy it all at once, and hope it works. When it does not, you have no rollback path because the old system is gone.

The Strangler Fig Pattern

Named after the strangler fig tree, which grows around a host tree and eventually replaces it, this pattern incrementally replaces a monolith with microservices.

Step 1: API Gateway

Place an API gateway in front of the monolith. All traffic goes through the gateway. Initially, the gateway routes everything to the monolith.

Step 2: Extract One Service

Choose the highest-value or highest-risk service. Build it as a microservice. Configure the gateway to route that service's endpoints to the new microservice.

Step 3: Run in Parallel

During migration, both the monolith and the new microservice run. The gateway can route to both. Use this period to compare outputs and verify correctness.

Step 4: Cut Over

Once the new service is stable, route all traffic to it. The monolith no longer handles that service's traffic.

Step 5: Repeat

Extract the next service. Repeat until the monolith is a shell. Then retire it.

Lessons from the GVIVE Migration

We migrated the GVIVE ID verification system using this pattern. The key decisions:

Started with the highest-traffic service. This validated the approach and provided the most immediate scaling benefit.

Shared the database during transition. Both monolith and microservice read from and wrote to the same PostgreSQL database. This eliminated data migration risk.

Parallel run testing. Both systems processed the same requests. We compared outputs for weeks before cutover.

Rollback ready. The gateway could route back to the monolith in seconds. We tested this rollback before cutover.

Conclusion

The strangler fig pattern is the safest way to migrate a monolith. It minimizes risk, provides rollback, and delivers value incrementally. Never do a big-bang migration if you can avoid it.