That's not clear at all to me. This system sounds extremely complex (which could be one of the causes of the problem!), so I don't see how we can assume that n

That's not clear at all to me. This system sounds extremely complex (which could be one of the causes of the problem!), so I don't see how we can assume that no bugs got introduced, nor that execution speed is the only metric that matters. Perhaps the existing socket-based solution simply used a bad timeout, and instead of a weekend of work to completely change the architecture of the system, it could have been fixed by changing one number in a configuration file. That would have been much lower risk, and not affected any other functionality, test suites, debugging practices, support procedures, etc. Software is still a young field that celebrates youth, and single combat warriors, like "Mel". It reminds me of Tom Wolfe's "The Right Stuff", about the U.S. space program back in the 1950's. One person could and did go do crazy heroic things that helped a single flight succeed. Eventually, space flight grew up, and NASA today barely even mentions the names of their contributors and collaborators. They'd never put up with cowboys like that any more. That's not how you achieve successful, repeatable results in complex systems. Or maybe I'm just getting old.