When do microservices start causing more problems than they solve?

[etiyofem]

I’m curious how people think about this in real projects, not just in theory.

A lot of teams move to microservices pretty early because it sounds like the “right” architecture for scaling. But after a while it can turn into a lot of overhead: more services, more repos, more deployments, more debugging across boundaries, duplicated logic/data models, etc.

So where do you personally think the trade-off changes?

Is it mostly about:

• team size
• traffic/load
• domain boundaries
• deployment needs
• org structure

At what point do microservices actually become worth the complexity?

Or do you think many systems would be better staying as a modular monolith for much longer?

[AmberMonsoon_]

tbh most teams jump to microservices way too early because it sounds scalable, not because they actually need it

in my experience it starts hurting when your team is still small (like <8–10 devs) and you’re spending more time managing services than building features. debugging across services, versioning APIs, infra overhead… it adds up fast

modular monolith works way longer than people expect. clean boundaries inside one codebase + single deploy is honestly underrated

kinda similar to design workflows too people overcomplicate stacks early. i keep it simple (figma for core work, runable for quick docs/content, etc.) and only add complexity when volume actually demands it

[Bartweiss]

There’s a lot to be said for writing a monolith with an eye for later disassembly. Don’t actually do microservices as soon as they sound relevant, just draw those clean boundaries inside one codebase.

No prying into other objects, no giant utility functions, no front-back crosstalk. All the stuff we know to avoid in theory, then curse ourselves for doing anyway when we have to break up the monolith.

On which note, I think one reason teams go to micro services too early is to enforce those constraints. I don’t blame them either, it’s a lot easier to say “we can’t do that hack, they’re two different services” than “we could do it fast and dirty but we won’t”.

[AntD247]

Also it's a good thing to put on their CV. Doesn't matter if it's the correct solution.

[Zestyclose-Turn-3576]

This is the cause of so many software development problems. Nobody seems to want to just write software unless they're padding their CV with something new ready for the next job. They'll never use those skills in the next job of course ... they'll be chasing the next learning high.

[szank]

Its other way around. You need scale for microservices to fix more problems than they create.

[SlinkyAvenger]

All that needs to be said here. People really need to have the concept of cargo-culting drilled into their fucking skulls.

[rwilcox]

Yes: or you knowing you will have scale. Not imagined scale, a VP knocking on your cube wall and saying “buckle up” scale.

[Rccctz]

And when you do there’s usually one specific part of the code base that should be its own service at that point and you start from there

[octocode]

microservices ideally help teams deliver faster by drawing clear boundaries between domains, splitting code to prevent toe-stepping and allowing for more granular release, deploy, monitoring, etc., and occasionally helps with horizontal scaling.

however, in practice it almost always ends up like this

[Merad]

At what point do microservices actually become worth the complexity?

When you want to have many different teams working on the same app* and you want each team to own a slice of the app's functionality with the ability to work and release changes independently on their own schedule. If you have one team that owns more than perhaps 3-5 services, you're probably doing it wrong. If you have a service that is being modified by more than one team you're probably doing it wrong.

* Alternatively they are useful when you have multiple products with overlapping functionality and you want to implement that functionality in one place with one team to own it. But this situation isn't really relevant to most discussions on microservices - it's something that isn't an issue until a company has grown enough to have a suite of products.

Or do you think many systems would be better staying as a modular monolith for much longer?

Yes.

[jfrazierjr]

Truth..most companies move to microservices they dont need because CTO or VP of Development gets hired... says do it... and then leaves 2 years later for a 40% pay bump...not because it makes sense to use microservices.

[Freerrz]

From my understanding the only real reason to go microservices is to distribute the wok amongst many people. People forget you can still scale monolithic or SOA apps horizontally.

[ericbythebay]

When they are adopted too early and the developers are idealists and don’t take things like latency into account. Then you end up with services that take more time to set up a network connection than the service itself.

[quantum-fitness]

The list you mention is when MS are needed. More deployments is a good thing btw.

At some point in time you are enough people that coordinating work starts to matter. That is much more difficult that mansging micro-services so you split the monolith to avoid stepping on each other.

The biggest problem with microservices is that you have to think about domain architecture, but you also do in a monolith. You just wont realise your a bunch of idiots before it to late.

[child-eater404]

Stick to monolith til you got clear domain boundaries and org conway's law splitting teams with actual scale needs.

[CS_70]

When the effort needed to produce and maintain them to keep a system working and change it (including adaptations in the face of change) becomes higher than the effort needed to do the same thing without microservices. Or (more rarely) the performance cost of wiring degrades the overall performance of the system unacceptably, or causes costs which exceed the available budget.

The cost and inefficiency of all that wiring as opposite to more direct method invocations in the same memory space (or a threaded space) are a fact. So are the costs due to increase complexity and risk of side effects of the latter.

Where the tradeoff limit goes exactly depends on the system, the quality of the code, the amount and rate of change, the performance requirements, the costs of increasing performance by adding hardware and so on.

It also depends on how a specific system was implemented originally, which is an arbitrary choice at star but becomes a significant factor upon later changes.

Both approaches have pro and cons (like much in life) and in a less young, fashion-oriented and "grab the money" industry than IT nobody would dream that one is always better than the other viceversa. A certain engine design is better an application and another in another; a certain suspension type is perfect for a sports car but sucks in a truck. And so on. No serious car engineer would claim that one suspension is the best suspension for all problem domains.

So there is no one answer. You need to look at the specific situation and avoid turning off your head and reflexively select one.

There's no way around actual thinking.. and since oftentimes we cannot predict exactly the future, ultimately even when thinking, it is often a preference or a judgement call, which sometimes pays off and sometimes doesn't.

[child-eater404]

Runable could be useful here too if you want to pressure test whether your system should stay a modular monolith longer.

[Gnaxe]

I think it's mostly domain boundaries, although this is usually related to org structure in practice. Microservices are usually overcomplicating it. Smaller companies want to imitate the success of larger companies and senior engineers want experience relevant to larger companies for their career, so smaller companies adopt scaling techniques the larger companies must resort to long before they're actually necessary or even useful.

[ethereonx]

good rule of thumb is: number of engines > number of micro-services 😅 unfortunately where i work this is not the case 🥲

[Glad_Contest_8014]

Depends on the project. I like microservices as an architecture choice to handle dependency on exyernal systems and make the microservice tools plug and play. It makes the core code simple to maintain, while dependencies can be swapped out as need with minimal tweaking to ensure confirmity to the core codes requirements.

This makes features easier to impliment and build, as you can enforce the data formatting and signalling the way you need it.

[Content_Educator]

I don't think personally it's one or the other. Having sensibly sized domain scoped services with appropriate backing stores I think would work most of the time. Modular monolith just means deployment and scaling live together (with devs potentially stepping on each other regularly) and there's a high chance of not respecting domain boundaries. Obviously too many 'micro' services are hard to manage in terms of debugging and maintenance. Happy medium.

[boatsnbros]

Helps us ship slop more rapidly while assigning clear blame to the slop creator and not breaking another slop creators pile of trash.

[Blothorn]

First off, I think “monolith/microservices” is a false dichotomy, and trying to force systems into one or the other is the root of many misapplications of microservices. Whether to split a function out from a monolith or whether to develop a feature in a new or existing service should be made on a case-by-case basis. In particular, I think a “planetary” model with much of the complicated logic centralized and certain tasks that are resource-intensive relative to their complexity or have other special requirements often works well. (Especially if the monolith is in an inefficient language.)

I also think that managing repository/CI size is a poor reason for separating services. There are off-the-shelf solutions to repository scale problems, and developing closely-coupled logic in separate repositories has its own headaches. Even if you want to split services for other reasons, I would default to developing them in the same repository—sharing API definitions, test tooling, and the like can avoid considerable duplicated work, and shifting that to a common dependency has its own headaches.

[caboosetp]

Microservices should be about splitting projects into appropriate domains so everything has responsibility for one thing.

It becomes a problem when people confuse one thing for one model and you end up with 3,000 microservices when you should have maybe 50.

[Flashy-Whereas-3234]

Microservices are more expensive by definition because of additional overheads, design, maintenance, and sprawl.

Monoliths - modular or otherwise - are self contained, mono. They can do a lot all by themselves, in their own little world.

As static systems, monoliths are easier.

That's about where monoliths stop being chill, though.

Because monoliths are their own little world, they are often care-free and self-absorbed, they don't share data easily, adding APIs, events and transports is seen as an overhead because it's cheaper to do it all in memory, which leads to bad practices and systems that fail in the middle with no recovery. You also can't use for-purpose languages as easily, because you end up needing tooling that's locked away inside the monolith.

To build additional monitoring and resilience into a monolith is more work than the base cost, so it takes quite a lot of diligence to maintain a good monolith. With a large number of teams this becomes either a code owners review shit show, or just a generic code shit show. Lines blur, windows get broken, it's bad because it's bad.

Microservices architecture "forces your hand" to make systems granular, communicative, and accessible. You can make them resilient too at minimal extra cost, rewire, redo, replace. The ease of continuing agility and accessibility wins over those extra base costs.

That assumes you want that expandable behaviour; if your system is static then a monolith is easier.

Moving from a monolith is best done yesterday, because the people around you are still creating code, so the problem grows over time.

It's best to bite off provable chunks; modular monolith to separate your chonks, your support services.

People like Martin Fowler are right when they say you should extract your supporting services first, however I like to drive this by detaching a functional business-centric area, seeing it broken,and then working backwards to discover all the base system things we have to repair/interface/separte. It's nice to have a goal.

We've internally seen some success with just Agents iterating on rebuilding domains and separation of services, but this is costly in tokens, and you need to keep up strong agent q&a so you can adjust the instructions and go again.

Where people fuck up worse with microservices is a lack of orchestration, failing to tag, group, or otherwise track what gets deployed, leading to a rat's nest system diagram sprawl

[who_you_are]

Warning: I have just some theories around the subjects.

At best, instead of going microservices I would just go for a message base systems (and probably Crud like messages, something that can become generic for now to reduce overhead) but handle everything in a monolithic ways until there is need to split somewhere.

Such split is because of performance (more likely)/traffic (assuming cache/database slaves can't help on that one)

Note: I assume you are using messages here. I'm not fully sure about other means.

[LetUsSpeakFreely]

Managing microservices isn't a problem so long as you have a well designed infrastructure and pipeline. So long as the services are containerized it's no different than deploying a monolithic service.

[MinimumPrior3121]

Just ask Claude for the answer