So, there was a single critical path, that for 2 hours per week was overwritten with the v2 code. This is pretty common. They wanted to test v2 in the regular

So, there was a single critical path, that for 2 hours per week was overwritten with the v2 code. This is pretty common. They wanted to test v2 in the regular environment, so they can see how it reacts to real user traffic. If it reacted well, they would replace v1 with v2 completely under the hood! See, they didn’t want v1 and v2, they wanted the existing endpoint updated while maintaining backwards compatibility!! Their system was too old or had poor test coverage, so in order to minimize risk of disruption to the service, they came up with the idea to try it out for 2 off-peak hours. Why do that vs better test coverage? They were confident enough, or the risk of breaking things for a little but was understood and justified, maybe they had some super old machines or configs they cannot accurately model and really wanted to get proper user traffic in. This is how many a/b tests happen too. Turn on feature for a segment, and then turn it back off. Or rolling deployments - have code run on 5% of servers then increase the percentage. Rollback if problem. This is that just except time based. Kinda hacky but everything in the story sounds reasonable to me