The promise: Microservices make your system scalable, maintainable, and fast.
The reality: For most systems, microservices add latency, complexity...
For further actions, you may consider blocking this person and/or reporting abuse
I called out many developers for choosing micro-service just because the trend said so.
and many of them designed crappy micro-services, 90% of the time it's some service will rely on another which completely violates the principal of a micro-service architecture.
I've worked on many architectures and I can safely assume 90% of startup projects out there will run exceptionally fine on a well-developed monolith.
You can't ship x number of distributed monoliths and call it micro-services.
You've hit the nail on the head. The "distributed monolith" anti-pattern is everywhere, and it's often worse than an actual monolith because you get all the downsides of distributed systems with none of the benefits.
What you're describing are classic violations of the Fallacies of Distributed Computing. The moment you have tight coupling between services, whether through deployment ordering, cascading failures, or synchronous dependencies, you've basically created a monolith that just happens to communicate over HTTP instead of function calls. And that's the worst of both worlds.
The deployment ordering issue is particularly telling. I've seen teams with elaborate orchestration scripts to deploy services in the "correct" sequence, and it's a giant red flag. If Service A absolutely requires Service B to be deployed first, they're not independent services, they're modules that should live in the same codebase.
Your 90% estimate for startups is generous, I'd argue it's closer to 95%. Most startups don't have the scale, team size, or organizational complexity that justify microservices. They're optimizing for problems they don't have yet while ignoring the ones they do have (shipping features, finding product-market fit, managing burn rate).
The irony is that by the time a startup actually needs microservices, they'll have enough engineering maturity to know when and how to extract them properly. If you're pre Series A and building microservices, you're probably doing it wrong.
the reasoning is right but don't forgot one thing:
A well developed microservice will perform better than a roughly developed monolith.
At the end it comes to the person or company who is developing that.
At the end, yes. It's all in the hands of the person or company
This is a fantastic breakdown—clear, data-driven, and refreshingly honest about the real trade-offs instead of repeating buzzwords. I really like your conclusion around modular monoliths; it aligns with my own experience that architecture should solve organizational needs, not just follow trends. I’d love to see a follow-up on modular monolith patterns or real migration stories, because this kind of grounded analysis is incredibly valuable.
happy to hear^^
😎
Very common scenario where people get hyped by fancy architecture and unrealistic promises, like it would solve all problems.
Those micro-services work best in the right context, so a few use cases.
Otherwise, you're forcing it, which usually creates more problems than it solves.
These concepts are pioneered by mega entities like Amazon and Netflix, because they have unusual cases to handle, and very special needs that push architectures to the limit.
Exactly. The cargo cult problem is real. Teams see Netflix/Amazon use microservices and think "we should too" without understanding the why.
When Netflix talks about microservices, they have infinite more resources than an avarage company. The context is completely different. It's like seeing an F1 team and thinking your daily commuter needs a $10M racing car. You need a Toyota, not a Formula 1.
Conference talks show the success stories but hide the prerequisites: dedicated platform teams, massive ops budgets, mature DevOps culture. A 10-person startup copying Netflix's architecture is setting up for failure.
The right question isn't "should we use microservices?" It's "what's the simplest solution to our actual problem?" Most of the time, microservices isn't it.
I think a decade of development was largely wasted on microservices dogma. For a while, everyone built everything as microservices, regardless of scale.
One overlooked issue is uptime. High availability, say 99%, is already hard to achieve for a single service. Once you start chaining services, downtime compounds fast. Three services in the chain at 99% uptime each give you ~97% overall uptime, and it only gets worse from there.
I totally agree
Complexity comparison is totally incorrect. I rather maintain 100 microservices with a clear design than maintain an equivalent monolithic app.
L take. Maintaining 100 microservices by yourself is essentially impossible. Maintaining a monolith with a similar number of routes and a single DB is objectively simpler. If the opposite were true, startups would launch MVP products as microservices, not monoliths. However, that almost never happens for a reason.
I mean... It's a personal thing, if you can do it, do it.
That's it! Great write-up. Very objective and straight to the point. Until you get the bounded context and granularity right to properly decompose your monolith, there's no point in starting with a microservice. Breaking up a monolith must be an empirical process. We need enough knowledge from real feedback before rushing into rearranging things.
Also, one must ALWAYS be aware of The Fallacies of Distributed Computing.
Useful
Great post! I immediately liked it after reading just this sentence: "The reality: For most systems, microservices add latency, complexity, and failure points without meaningful benefits."
The decision matrix is also great!
Just one thing to consider: in the Database Contention section, you're assuming that all microservices share the same database, but each service should ideally have its own database => Database per Service pattern. So this might not be a well-suited metric for microservices.
Really interesting article!
I'm curious about the microservices chain. Is it really necessary or this integration/communication between microservices could be decoupled through a event system like Kafka?
My rules of thumb for distributed architectures are:
The article raises interesting points and is well written, but I disagree with its conclusion.
Modern businesses need scalable systems, fast delivery, and independent releases. Achieving this requires the right technology stack and a strong Dev + Architecture + Ops collaboration.
In Kubernetes-based environments, even network-level dependency injection can be slower than a direct HTTP call, so microservices must be designed with a solid internal architecture and minimal cross-service communication. A microservice should not rely on excessive HTTP calls to function.
A good practice is:
• One bounded context
• One code repository
• One dedicated physical database cluster
This approach improves ownership, isolation, and scalability.
In the Java ecosystem, Spring Cloud is currently the only platform that provides a truly comprehensive set of capabilities required for building distributed systems at scale.
Finally, replacing or evolving a single microservice is significantly easier than changing a monolith. Under high load, monolithic architectures struggle to scale effectively, while well-designed microservices can evolve and scale independently.
The premise that modern companies require independent releases and "scalability" is incorrect. It assumes most businesses have large dev resources and enormous swings in usage patterns. Those assumptions are false.
Reminder that most businesses with devs have a team of less than 5 people. Independent releases hardly contribute anything at that team size.
Reminder that most businesses have predictable base load requirements and don't experience the dramatic swings in usage that make "scalability" a challenge. Most businesses service less than 10K entities total and are easily within the performance budget of a single moderate vps. Independent scalability is only useful if your dev team is large enough to require independent teams or your network / processing demand changes wildly enough that the difference between high and low demand consumes a large portion of a dev salary in server resources. Without those situations, "scalability" is a waste of resources (spending dollars to pinch pennies).
Fast delivery, yup agree with you there. Every business would prefer features to be delivered yesterday, or last quarter if possible. That is why it is critically important to not waste time building things that aren't necessary. The fastest and cheapest code is no code. The fastest and cheapest infrastructure is no infrastructure. The fastest and cheapest CI/CD pipeline is one that never had to be built because the code it would manage was never written.
Extensively explained and the trade offs are well written. But Why .Net is not there in the recommended framework.. lol !!!!
A really nice article on hype of miroservices architecture. I read that even stack-overflow is using monolith architecture
Excellent article! I will include it in my newsletter. 🙂
Thank you, feel free to use it^^
if there is an exception in the code somehow one service is crashed whole app will down
It looks like an AI‑generated post. Each case is unique. If you think a microservice is needed, you should carefully weigh the pros and cons - that’s what really matters. Architecture exists to help solve problems, and choosing the right architecture is the responsibility of the developer.
As said in other comments, it depends by developer and the final choise is yours. Yes i usually use the AI for correct my initial text, because english is not my main language and services like deepl or google translate aren't really good in this type of use case
Every architecture comes with a cost, so it must be chosen wisely. If the architecture impacts the investor’s pocket too heavily, it won’t be sustainable and is bound to fail sooner rather than later.