There's definitely pros and cons to this approach.

The pro being that every service is an island that can be independently updated and managed when needs be. Scaling is also somewhat nicer as you only need to scale the services under heavy load rather than larger services.

It also makes for better separation of systems. The foo system gets a foo database and when both are under load we only have to discuss increasing hardware for the foo system/database and not the everything database.

The cons are that it's more complex and consistency is nearly impossible (though we are mostly consistent). It also means that if we need a system wide replacement of a service like redis, you have to visit our 100+ services to see who depends on it. That rarely comes up as most companies don't do what redis did.

Indeed. Microservice zealot 'architects' love to ignore the work that has to into each microservice and the overhead of collaboration between services. They'll spend a couple of years pretending to work on that problem in any meaningful way, then move on to a different company to cause similar chaos

that’s a loaded statement without understanding the company.

Sometimes large companies acquire smaller companies and keep the lights on in the old system for a while. They may not even use a similar tech stack!

Sometimes they want to cleanly incorporate the acquired systems into the existing architecture but that might take years of development time.

Sometimes having a distributed system can be beneficial. Pros / cons.

and sometimes it’s just a big company with many people working in parallel, where it’s hard to deploy everything as a single web app in a single pipeline.