Tactical Forking

Tactical forking is a technique that can assist with restructuring or migrating from monolithic codebases to microservices.

Sometimes multiple teams work on the same code base but with different needs and business priorities, this will lead to infers communication and overhead in coordination between them at different points of the development cycle, Increasing the cycle time, time to recover from errors etc…

In such cases some teams choose to decouple themselves from the other teams and take their domains somewhere else. For this, many use techniques such as the Strangler Application or Some of them even choose to migrate their own domain to a new application which is completely independent.

Those techniques will be successful when dealing with legacy systems or with third-party systems, But when it comes to application in constant evolution, those techniques need a huge effort even before starting to get a real benefit. Sometimes this will also lead to endless efforts, which in many circumstances can take a very long time or be very challenging to achieve.

To this extraction can be used, we can either take off that one particular area or keep that piece and remove the rest.

From this thinking , we could duplicate the application by deleting the unnecessary code. By this method teams can get their own version of the application and start working on it, this can reduce the coordination with other teams. This method is called Tactical Forking.

The main benefits of using tactical forking is each team can have their own work flow and methods without affecting or depending on the other teams.


Forking (Duplication)

It is necessary to create a copy of the application and its deployment mechanism .


It is necessary to have a routing mechanism that allows users or consumers to access the different parts of the application.


This is a key point, it is necessary to constantly refactor the code of the new application eliminating unnecessary code to have a more maintainable code base.


  • Teams can start working Individually without communicating with other teams.
  • Teams can start working right away with virtually no up-front analysis.
  • Developers find it easier to delete code rather than extract it. Extracting code from a chaotic codebase presents difficulties because of high coupling, whereas code not needed can be verified by compilation or simple testing.


  • The resulting services will likely still contain a large amount of mostly latent code left over from the monolith.
  • Inconsistencies may occur between the naming of shared code and shared component files, resulting in difficulty identifying common code and keeping it consistent.
  • Unless developers undertake additional efforts, the code inside the newly derived services won’t be better than the chaotic code from the monolith—there’s just less of it.

Conclusion :-

There are occasions in which an application was developed by a team and then other teams joined the same code base to implement other modules with different business needs, reaching a state in which there is too much coordination and communication for deployment, Correction of errors and even blockades to commit in the code due to pipelines broken by other equipment.Mind the “ Tactical Forking “ it’s the first step, not the last one.
For more details contact info@vafion.com

Follow us on Social media  : Twitter |  Facebook | Instagram | Linkedin

Similar Posts:

    No similar blogs

Related Posts

Stay UpdatedSubscribe and Get the latest updates from Vafion