[kukkeliskuu]

The biggest beef I have with microservice architectures is lack of transactions across service boundaries. We say that such systems-of-systems are "eventually consistent", but they are actually never guaranteed to be in a consistent state -- i.e. they are always inconsistent. That pushes the responsibility for consistency to the system that needs to use the data -- making implementing those either extremely complex -- or more typically -- ignore the problem and introduce distributed timing bugs that are difficult to find in testing. The benefits of microservices are offset by losing the ability to build on database functionality to make your systems robust.

[zmmmmm]

It definitely seems like the value of losing of transactional integrity is massively under appreciated. I think there has been a progression of thinking over the last couple of decades that went from laying everything at the god of transactional integrity, to "planet scale" services proving that such designs cannot scale and hence promulgating distributed solutions, to everyone else cargo culting the idea that transactions never mattered in the first place and now even a simple app that never needed to scale in the first place is being carved up into 5 microservices and half the design complexity is dealing with regaining the lost transactional integrity that we had in the first place.

[SOLAR_FIELDS]

The biggest beef I currently have with microservice architectures is that they are more annoying to work with when working with LLM's. Ultimately that is probably the biggest limiting factor for microservices in 2026, the tooling for multi repo setups is there (i've been using RepoPrompt for this with really good effect), but fundamentally LLM's in their default state without a purpose designed too like this suck at microservices compared to a monorepo.

You could also turn around and say that it's a good context boundary for the LLM, which is true, but then you're back at the same problem microservices have always had: they push the integration work onto another team so that developers can make it Not Their Problem. Which is, honestly, just a restatement of the exact thing you just said framed in a different way.

I think your statement can also be used against event driven architecture - having this massive event bus that controls all the levers of your distributed system always sounds great in theory, but in practice you end up with almost the exact same problem as what you just described, because the tooling for offering those integration guarantees is just not nearly as robust as a centralized database.

[weitendorf]

I have found mostly the opposite but partly the same. With the right tooling LLMs are IMO much better in microservice architectures. If you're regularly needing to do multi-repo PRs or share code between repos as they work, to me that is a sign that you weren't really "doing microservices" before adding LLMs to your project, because there should be some kind of API surface that you can share with LLMs in other repos, and cross-service changes should generally probably not be done by the same agent

Even if the same dev is driving the work, it's like having a junior engineer do a cross-service staggered release and letting them skip the well-defined existing API surfaces. The entire point of microservices is that you are making that hard/introducing friction to that stuff on purpose so things can be released and developed separately. IMO it has an easy solution too, just direct one agent per repo/service the way you would if you really did need to make that kind of change anyway and wanted to do it through junior developers.

> hey push the integration work onto another team so that developers can make it Not Their Problem

I mean yes and no, this is oftentimes completely intended from the perspective of the people making the decision to do microservices. It's a way to constrain the way people develop and coordinate with each other precisely because you don't want all 50 of your developers running amok on the entire codebase (especially when they don't know how or why that code was structured some way originally, and they aren't very skilled or conscientious in integrating things maintainably or testing existing behavior).

> so that developers can make it Not Their Problem

IMO this is partially orthogonal to the problem. Microservices doesn't necessarily mean you can't modify another team's code. IMO that is a generally pretty counter productive mindset for engineering teams where codebase is jealously guarded like that. It just means you might need to send another team a PR or coordinate with them first rather than making the change unilaterally. Or maybe you just want to release the things separately; lately I find myself wanting that more and more because past a certain size agents just turn repos into balls of mud or start re implementing things.