Sure, but likely that team is not working on a single service when people say microservices. That could be SOA, which is more my preference, but definitely not

Sure, but likely that team is not working on a single service when people say microservices. That could be SOA, which is more my preference, but definitely not a microservice going by the most popular definition which is "small enough to rewrite." > BTW, monolith DB has its own form of eventual consistency. Sure, on very large systems. Microservices always have this - even tiny systems. > It gives you a smaller blast radius when something goes wrong, At the cost of often having a much harder time fixing things when they do go wrong :) > avoids over-stressing a single DB, Monoliths can use as many databases as they want! And you can use a single DB with a microservice architecture across many microservices (tho I think this is an anti-pattern, teams often do it). > alleviates single points of human dependency like the DB curator, I haven't been at a job that has a DB curator, but it compounds the "bob wrote those ten services in rust, who... who knows rust? anyone?" issues :) > lets you scale separate pieces independently, You can do this with a monolith with many technologies, though seems easier to do for a microservice as a general rule. But, you have to need that scale first! > and yes forces you to silo the data. There are several good reasons larger orgs have been doing things this way for a long time. Plenty of larger orgs also avoid microservices!