Man, this is a frustrating and shallow criticism. Obviously this is over-engineered. It's a demonstration of how these patterns would fit together in an application that required them.
Agree it's not the best criticism, but there's at least some validity to it. I think the main issue is that this is an extremely heavyweight architecture that will incur a disproportionate level of administrative overhead - you would need an ample team of competent full-time devs to build and maintain this system properly. It's like an advertisement for a giant excavator where the excavator is featured crushing a soda can. It's an impressive piece of machinery, but the task being used to demonstrate it is comically mismatched with its true capabilities.
True, true. That's a fairer way to formulate it. But like, it's supposed to be an extremely heavyweight architecture. The benefits of microservices are arguably only apparent when you have an ample team (or teams!) of competent full-time devs.
You're right they could have... beefed up the soda can, so to speak, but I don't blame the (presumably) DevRel folks who put this together for hand-waving it, "now imagine a mountain here".
> The benefits of microservices are arguably only apparent when you have an ample team (or teams!) of competent full-time devs.
I would very much agree with that. Although I'm not against microservices, they are by no means a quick or efficient way to get things done. Hedging against future theoretical scaling concerns comes at a high cost - a cost that's very much worth it if true scale is achieved, but a high cost nonetheless.