Lessons learned from the cargo cult of microservices:
Your application architecture should not 1:1 reflect the Services of your Domain Model (if you are adhering to Domain Driven Design).
If you do not have any software design discipline, your engineers will reliably build unmaintainable garbage.
The problem with implementing every DDD service as a "microservice" is the amount of complexity you add to the intercommunication of those services. No, HTTP REST is not free. It is in fact very expensive to maintain.
Strangler Pattern exists to address monoliths that exist in practice, not to avoid monoliths that exist in theory.
If you have to ask why you're doing microservices, chances are you do not need microservices.
And I return to the point about the domain model not being treated as an architectural blueprint:
The network is the most fragile part of your architecture. If you take it for granted, your systems will become failure-prone messes.
Don't do microservices, until you truly need it.
This is me speaking from 2+ years of experience building greenfield products adopting "industry standard" practices. Doing that was a mistake that we keep repeating.
The industry standard should not be treated as a given. If your engineering team doesn't have the technical discipline to explain why you need the industry standard, then you shouldn't use the industry standard.
If you can solve a business need by adding a route to your JAX-RS resource class, then just fucking do that. If it has scaling issues, then address them. But only when you know you need to.
You don't need to spin up 8 instances of a new application with its own interface and maintenance contract just for one HTTP route.
Not only is it maintenance hell inducing, it's just pointlessly wasteful.
For the same reason, you don't need a NoSQL database like Cassandra unless you know you need one. Just create a new schema in your existing RDBMS and watch its performance closely. Chances are it works fine for your use case.
The reason people make jokes about MongoDB is because cargo culting around it is a real fucking problem. It's not a silver bullet, just like microservices isn't a silver bullet.
And for that matter, GraphQL isn't a silver bullet either.
This is enough of me ranting at 3am. I have seen some shockingly incompetent architectural stuff over the last few years and it makes me want to write books on how bad this industry is at getting shit done.
The efforts done to make microservices architecture "easy" were themselves incredibly expensive. So why did anyone invest into it?
Because the companies that went to it had a practical need to break things down into smaller components, and it was cheaper to invest in the research for e.g. gRPC or other technologies that make the implementation of microservices more robust than to continue scaling vertically.