Both approaches can fail. Especially in environments like Node.js or Python, there's a clear limit to how much code an event loop can handle before performance seriously degrades.

I managed a product where a team of 6–8 people handles 200+ microservices. I've also managed other teams at the same time on another product where 80+ people managed a monolith.

What i learned? Both approaches have pros and cons.

With microservices, it's much easier to push isolated changes with just one or two people. At the same time, global changes become significantly harder.

That's the trade-off, and your mental model needs to align with your business logic. If your software solves a tightly connected business problem, microservices probably aren't the right fit.

On the other hand, if you have a multitude of integrations with different lifecycles but a stable internal protocol, microservices can be a lifesaver.

If someone tries to tell you one approach is universally better, they're being dogmatic/religious rather than rational.

Ultimately, it's not about architecture, it's about how you build abstractions and approach testing and decoupling.

▲

dragonwriter 17 minutes ago | parent | next [-]

> If your software solves a tightly connected business problem, microservices probably aren't the right fit.

If your software solves a single business problem, it probably belongs in a single (still micro!) service under the theory underlying microservices, in which the "micro" is defined in business terms.

If you are building services at a lower level than that, they aren't microservices (they may be nanoservices.)

▲

rubenvanwyk 29 minutes ago | parent | prev | next [-]

Wait, do people at scale use NodeJS and Python for services? I assume always it’s Go, Java, C# etc.

▲

rozap 9 hours ago | parent | prev | next [-]

To me this rationalization has always felt like duct tape over the real problem, which is that the runtime is poorly suited to what people are trying to do.

These problems are effectively solved on beam, the jvm, rust, go, etc.

▲

strken 9 hours ago | parent | prev [-]

Can you explain a bit more about what you mean by a limit on how much code an event loop can handle? What's the limit, numerically, and which units does it use? Are you running out of CPU cache?

	▲	joker666 8 hours ago \| parent \| next [-]
		I assume he means, how much work you let the event loop do without yielding. It doesn't matter if there's 200K lines of code but no real traffic to keep the event loop busy.
	▲	BoorishBears 2 hours ago \| parent \| prev [-]
		Most people don't realize their applications are running like dogwater on Node because serverless is letting them smooth it over by paying 4x what they would be paying if they moved 10 or so lines of code and a few regexes to a web worker. (and I say that as someone who caught themselves doing the same: severless is really good at hiding this.)