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^^
😎
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
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.
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.
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.
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.
A really nice article on hype of miroservices architecture. I read that even stack-overflow is using monolith architecture
Extensively explained and the trade offs are well written. But Why .Net is not there in the recommended framework.. lol !!!!
if there is an exception in the code somehow one service is crashed whole app will down
Excellent article! I will include it in my newsletter. 🙂
Thank you, feel free to use it^^
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
This is not a well-done article, I am sorry, I have to point it out. You are comparing a optimized monolith with a poorly done microservice. You have done a disservice to your users by assuming
I do agree that startups should use monoliths and migrate later. And I go agree with most of your conclusions. That startups should optimise for delivering features to their users. I felt, however, that for an article that pretends to educate people on the different strengths of monoliths vs microservices, you did not lean well enough into the strengths of microservices and why some teams choose them. You mentioned it, but you glossed over it. eg you mention the 99.9% reliability summation but don't go deeper, ignoring that monoliths have single points of failure while with microservices, if the email service is down, messages will be buffered into a queue and delivered when the service comes back online.
This might just be me misunderstanding the point of this article, I'll admit I've read it more than once to try and get the point. You lean into the strengths of monoliths while glossing over the strengths of microservice architectures and why people might choose them so I do not feel this article is comprehensive enough to educate people on which option makes sense when.
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.