Parallel run with reconciliation

This blip is not on the current edition of the Radar. If it was on one of the last few editions it is likely that it is still relevant. If the blip is older it might no longer be relevant and our assessment might be different today. Unfortunately, we simply don't have the bandwidth to continuously review blips from previous editions of the RadarUnderstand more
Published: Oct 28, 2020
Oct 2020

Replacing legacy code at scale is always a difficult endeavor and one that often benefits from executing a parallel run with reconciliation. In practice, the technique relies on executing the same production flow through both the old and new code, returning the response from the legacy code but comparing the results to gain confidence in the new code. Despite being an old technique, we've seen more robust implementations in recent years building on continuous delivery practices such as canary releases and feature toggles and extending them by adding an extra layer of experimentation and data analysis to compare live results. We've even used the approach to compare cross-functional results such as response time. Although we've used the technique multiple times with bespoke tooling, we certainly owe a nod to GitHub's Scientist tool, which they used to modernize a critical piece of their application and which has now been ported to multiple languages.