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.
if you need to deploy in order, you're violating it
if your app wont work because one service is down, you're violating it
if one goes down, causing others to go down with it, you're violating it
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.