The Strangler-Fig is a critical refactoring tool.  The implementation sounds easy: wrap the existing code with the strangler, and replace the references over time.  This glosses over an important implementation detail – there’s an order to wrapping code: The outputs have to go before the inputs.

Strangler-Fig Examples Are Single Step

Oftentimes you can fully wrap the strangler around the existing code in a single step.  For example, Amazon’s Elastic Load Balancer can be used as a Strangler.  It instantly proxies all requests to a service; and makes it easy to migrate routes to a new service over time.

Systems with Multiple Outputs Need Multiple Stranglers

That works great for simple architectures with a single entrance and exit.  But what about something more complicated?  What if your system has a RESTful interface for data inputs and then publishes events onto Kafka?

Because the system has one input and two outputs, a single strangler like ELB is insufficient.

This system requires 2 different strangler-fig implementations.  An ELB, or web proxy, to handle RESTful communication, and kafka to proxy the communications from the service to kafka.

Even in an ideal world, where you can put the proxies into place with just simple config changes, this is a two step process.  More realistically, there will be weeks or months between setting up the first strangler, and the second.

The Partial Strangle Limits Options

Remember, the goal of the Strangler-Fig pattern is to squeeze out the original system over time.

A partial strangle limits your options.  

Doing ELB first lets you redirect RESTful inputs and outputs, but won’t populate the kafka stream.  This will break your system if you attempt to migrate any endpoints.  The Writeback anti-pattern, where the new system will write to the original system for the benefit of downstream listeners, is a common solution.

Putting the first strangler around the Kafka connection won’t break anything, and creates limited opportunity for migration.  Any messages that can be generated outside of the REST inputs can be migrated in this state.

For Complex Systems, Strangle The Outputs First

The Strangler-Fig pattern should be in every developer’s toolbox; there is nothing better for reducing risk during refactors.  If you have a complicated system, with more than one type of output, you will need multiple stranglers, and the order of application is critical.  Apply the stranglers to pure outputs first, input/output groups second, and pure inputs last.

Applying the stranglers in the wrong order will lead you to implement anti-patterns like The Writeback.  Far from making the transition easier and lower risk, the anti-patterns will make your work harder and riskier.