Strangler fig pattern

While reading Building Microservices: Designing Fine-Grained Systems a few weeks ago and Monolith to Microservices: Evolutionary Patterns To Transform Your Monolith by Sam Newman I came across an interesting pattern called Strangler fig that is designed to help exclude some system functionalities, e.g. to the new module or new app. A few simple steps can save time and stress, so I think it is worth exploring.

Genesis

Strangler fig is a pattern proposed by Martin Fowler a long time ago. It consists of iteration working on excluding system functionalities on a few simple steps with the possibility to revert changes that are not working as we expected.

What problems it resolves

Often, when trying to replace one system with another, you encounter many bugs, and in the end, it turns out not as easy as it looks. You have to go back to your old system, fix bugs in the new one and try again (but sometimes you have to fix bugs very fast on the new system because you cannot go back to the previous one). Strangler fig pattern helps you to migrate in a way that enables you to test the new system very carefully on low traffic and quickly and securely back to the old one if you encounter problems.

Steps

In basics, you need to follow three simple steps for your mental health during migration.

Identify

The first step is to identify the part of the system you want to exclude to the new module or service.

Implementation

In the second step, you must implement identified functionalities individually. It’s important not to change the behaviour of anything. If you found a bug, consider creating a task for the future to remember about it, but do not try to fix it because it may be difficult or even impossible to return to the previous flow.

Call redirection

In the end, you must redirect traffic from the first flow (for example, from the endpoint in system A) to the new one (to system B). If you are changing calls within one system, remember to change all calls and consider using, for example, a feature toggle to control the flow.

Reverse proxy

If you are changing traffic from another system, you should consider using the reverse proxy to redirect a small amount of traffic to the new system (canary release) in order to quietly observe if any bugs appear, but at the same time so that your application users are not cut off en masse from working functionality (canary release).

What to look out for

As I mentioned earlier, one of the most important things is to allow you to switch back to the old code quickly. Because of that, it is recommended not to fix bugs during migration.