a well-structured monolith will outperform a poorly-structured microservices architecture every time. the monolith's failure mode is spaghetti code. the microservices failure mode is distributed spaghetti code, which is spaghetti code that's also a networking problem.
microservices solve an organizational problem (letting independent teams deploy independently), not a technical problem. if you have one team, microservices buy you nothing except operational complexity.
the real question isn't "monolith or microservices?" it's "how many independent teams need to deploy independently?" if the answer is "one" or "two," the monolith is the better architecture. if the answer is "twenty," you need service boundaries, but you also need an infrastructure team to manage the complexity you've created.
i've seen a four-person startup running twelve microservices. they spent more time debugging network issues between their services than building features. a single Rails monolith would have been faster to develop, easier to debug, and cheaper to run.
the technology industry has a persistent pattern of taking solutions to large-company problems and marketing them to small companies. kubernetes, microservices, and event-driven architecture are all excellent solutions. they just solve problems that most companies don't have.
status: this is a hill i continue to die on. updated with new examples periodically.