So the initial problem was a single queue? Well, then split the queue, no need to go all crazy splitting all the code.
Switching to 100+ microservices? There is no need to switch to 100+ repos too, runtime services don't need to have one repo per service, just use a modular approach, or even feature flags.
100+ microservices, some of them with much lower load than others? Then consolidate the lower load ones, no need to consolidate "all" of the microservices at once.
Library inconsistencies between services? No, just no, always use the same library version for all services. Automate importing/updating the libraries if you need to.
A single change breaks tests in a way you need to fix unrelated code? WTF, don't you have unit tests to ensure service boundary consistency and API contracts?
Little motivation to clean up failing tests? Yeah... you're doing it wrong.
Only then you figure out to record traffic for the tests? HUGE FACEPALM, that's the FIRST thing you should do when dealing with remote services!
> Library inconsistencies between services? No, just no, always use the same library version for all services. Automate importing/updating the libraries if you need to.
This answer drove me crazy in the article. "We had trouble keeping the libraries up to date and fixing breakages, so our solution was... to update them all and fix the breakages." And per your second point, tests can go both ways - if libX is used by serviceY, write a libX integration test for serviceY instead of / in addition to a serviceY integration test for libX.
> Library inconsistencies between services? No, just no, always use the same library version for all services. Automate importing/updating the libraries if you need to.
If you did this then you'd have to go and update all services whenever you wanted to introduce a breaking change. I don't think what you're suggesting is as easy as it sounds.
Depends on how the library is used. If the change to the library will change how the service behaves externally (to either upstream or downstream services), then you indeed need to update them all simultaneously. However, that has the smell of poorly-defined API contracts (or poor implementations) if that is possible.
Otherwise, just update to the latest library versions whenever you touch a codebase.
So the initial problem was a single queue? Well, then split the queue, no need to go all crazy splitting all the code.
Switching to 100+ microservices? There is no need to switch to 100+ repos too, runtime services don't need to have one repo per service, just use a modular approach, or even feature flags.
100+ microservices, some of them with much lower load than others? Then consolidate the lower load ones, no need to consolidate "all" of the microservices at once.
Library inconsistencies between services? No, just no, always use the same library version for all services. Automate importing/updating the libraries if you need to.
A single change breaks tests in a way you need to fix unrelated code? WTF, don't you have unit tests to ensure service boundary consistency and API contracts?
Little motivation to clean up failing tests? Yeah... you're doing it wrong.
Only then you figure out to record traffic for the tests? HUGE FACEPALM, that's the FIRST thing you should do when dealing with remote services!