You Don't Need Microservices (Yet): A Reality Check for Devs
How Premature Architecture Decisions Slow Down Teams and Burn Engi...
For further actions, you may consider blocking this person and/or reporting abuse
timing isn't the real question - team topology is. three independent teams with different release cadences on a monolith creates the exact coordination debt you're trying to avoid. Conway's law doesn't care how young the project is.
That's a fair point. Conway's Law absolutely matters, and team topology can become a stronger driver than project age.
My argument isn't that timing is the only factor, but that many teams adopt microservices before they've actually experienced the coordination problems they're trying to solve.
Even with multiple teams and different release cadences, a modular monolith can often provide enough separation early on, while avoiding the operational complexity of a distributed system. Once team boundaries, ownership, and communication patterns are stable, microservices become a much more informed architectural decision rather than a default one.
In other words, I'd say team topology is one of the strongest signals that you're approaching the point where microservices might make sense, not necessarily proof that you need them from day one.
makes sense. the premature adoption problem and the team topology problem usually arrive together - teams copy the architecture without the org structure that makes it work. that is where the coordination pain lives.
I completely agree with that.
A lot of the successful microservice stories people point to came from organizations that already had clear domain ownership, autonomous teams, and strong engineering practices. What often gets copied is the architecture, not the organizational context that enabled it.
In that sense, microservices aren't really a solution to coordination problems by themselves—they're often an amplification of existing team structures. If ownership and boundaries are unclear, splitting a monolith can simply move the coordination overhead from code to network calls and service contracts.
That's why I tend to see team topology as one of the most important prerequisites. When independent teams genuinely need autonomy and the organizational boundaries are already well-defined, microservices can be a natural evolution. Without that foundation, they often create more complexity than they remove.
Appreciate the insight, it highlights an important dimension that architecture discussions sometimes overlook.
"the organizational context that enabled it" is exactly what doesn’t show up in any architecture diagram. domain ownership and autonomous teams took years to evolve at the reference orgs. teams that copy the architecture without that backstory are importing coordination overhead along with the service boundaries — and the overhead arrives immediately while the domain clarity takes years.
Great article, @gavincettolo . I think a lot of developers confuse architectural sophistication with architectural necessity.
What resonated with me most is the point about teams adopting distributed systems before they’ve even experienced monolith pain. Suddenly they’re managing retries, observability, orchestration, eventual consistency, and service contracts… for an app with 5k users and a 4-person team.
I’ve seen startups spend more time maintaining infrastructure than shipping product.
That said, I do think microservices can be valuable earlier if the domain boundaries are extremely clear from day one — for example in fintech, logistics, or large multi-tenant SaaS platforms. The problem is that many teams copy Netflix architecture without Netflix-scale problems.
Do you think the industry is finally swinging back toward modular monoliths, or are we just in another pendulum phase?
Thanks, @elenchen, and yes, I completely agree with the “architectural sophistication” point.
A lot of teams underestimate the operational tax of distributed systems. Once network boundaries enter the picture, every simple interaction becomes a reliability problem. Debugging alone becomes dramatically harder.
And honestly, most early-stage products still don’t fully understand their own domain model yet. Splitting services too early often means freezing bad boundaries into the architecture.
I’m not anti-microservices at all, they absolutely solve real organizational and scaling problems. But I think many teams adopt them as a default instead of as a response to concrete pain.
As for the pendulum: I do think we’re seeing a shift back toward modular monoliths and “monolith-first” thinking. Especially as more senior engineers openly talk about the hidden costs of distributed systems.
The interesting part is that even companies famous for microservices are now emphasizing consolidation, internal platforms, and reducing service sprawl.
That’s the key insight for me: microservices are often an organizational scaling strategy more than a technical one.
A small team with strong ownership can move incredibly fast inside a well-structured monolith. But once communication overhead between teams becomes the bottleneck, service boundaries start making more sense.
I also think developers underestimate how much tooling maturity companies like Amazon, Uber, or Spotify had to build internally before microservices became sustainable for them.
People see the architecture diagrams — they don’t see the years of platform engineering behind them.
Another thing I appreciated in your article is the distinction between “modularity” and “distribution.” Those are not the same thing, yet they’re constantly treated as interchangeable.
You can have excellent modularity inside a monolith.
You can also have a chaotic distributed monolith.
Exactly. “Distributed monolith” is probably the most common outcome when teams move too early.
Shared databases, tightly coupled deployments, synchronous dependencies everywhere, technically multiple services, but operationally still one giant system with extra failure modes.
I think the healthiest approach is:
Start simple → enforce boundaries internally → extract services only where the pressure is real.
That path tends to preserve developer velocity much longer.
And honestly, simplicity is underrated in our industry. We often reward complexity because it looks scalable, even when it slows teams down in practice.
Absolutely. Sometimes the most senior engineering decision is resisting unnecessary complexity.
“Can we keep this boring for another year?” is probably a more valuable architecture question than “How do we make this internet-scale today?” 😄
This perspective is a necessary reality check for many teams. Prematurely adopting complex distributed architectures often creates operational overhead that outweighs any perceived scalability benefits. Focusing on modular monoliths allows for cleaner boundaries without the added latency.
Exactly. A lot of teams jump into microservices chasing “scalability” before they even hit the limits of a well-structured monolith. In many cases, they end up trading simple in-process calls for network latency, deployment complexity, observability challenges, and operational costs they didn’t actually need.
That’s why I think modular monoliths are such an underrated middle ground: you still enforce boundaries and separation of concerns, but without introducing distributed-system problems too early.
Microservices absolutely make sense at the right stage, but architecture should solve current business problems, not hypothetical future ones.
Many startups accidentally optimize for future scale while slowing down present execution. The future problem may never arrive, but the complexity cost arrives immediately.
Exactly. A lot of teams end up paying the “complexity tax” long before they ever see the benefits of distributed systems.
Microservices solve organizational and scaling problems, but many early-stage startups mostly have execution problems: shipping fast, validating ideas, and keeping maintenance low.
If you introduce network boundaries, async communication, deployment orchestration, observability, and service coordination too early, you’re essentially trading current velocity for hypothetical future scalability.
And as you said, that future scale may never happen, but the operational overhead is guaranteed from day one.
The article is right—debugging distributed systems can be tricky if you jump into microservices too soon. The point about a "modular monolith" meeting most teams' needs before reaching a huge scale is accurate. I was getting bogged down in system design details until I found a solid approach on PracHub. Their bank for system design mocks includes the follow-up questions you'd face, which saved me from overengineering a solution. It helped me focus on what's relevant without getting swept up in the microservices hype.
That’s a great point. I think a lot of developers fall into the trap of designing for “internet scale” before they’ve even validated the real bottlenecks of their application.
Distributed systems introduce a whole new category of complexity: tracing requests across services, handling retries/failures, managing eventual consistency, deployment orchestration, observability, and so on. Those are real problems, and they only become worth solving when the business actually needs that level of scale or team autonomy.
I also agree that good system design practice helps separate what’s theoretically “cool” from what’s practically useful. A modular monolith is often the most pragmatic choice because it keeps the architecture evolvable without paying the operational cost too early.
Great article. I am glad to see people speaking out about the pitfalls of microservices and how they often devolve into a distributed monolith. The amount of unnecessary overhead and complexity they bring to a small project causes so much systemic drag. To paraphrase Martin Fowler, "the first rule of distributed systems is: don't distribute your systems!" (until you HAVE to)
Exactly, the “distributed monolith” is probably one of the most common outcomes of premature microservice adoption.
Teams often split services too early, but the services still end up tightly coupled through synchronous calls, shared databases, or deployment dependencies. At that point, you inherit all the downsides of distributed systems without gaining the real benefits of independent scalability or autonomy.
And yes, that Fowler quote captures the core idea perfectly (thanks for having shared it 🙂). Distributed systems solve specific problems, but they also introduce network failures, observability complexity, retries, consistency issues, and operational overhead by default. If a modular monolith can handle the current scale and team structure, that’s usually the simpler, and often better, engineering decision.
Architecture should evolve from real constraints, not trends.
The reality check most teams need is even simpler than 'don't do microservices yet': most of the operational cost shows up before the architectural payoff does. By the time the system is big enough to justify the split, the cost of doing it has compounded for two years. Wait until the boundary is obvious, not until the headcount is.
Exactly. Team size is often a poor proxy for architectural complexity.
The trap is that the operational burden of microservices starts on day one (deployment pipelines, observability, service ownership, network failures, versioning) while the benefits only emerge once clear domain boundaries and scaling constraints actually exist.
If those boundaries aren't obvious yet, splitting too early usually means you're paying distributed-systems costs without solving a distributed-systems problem. Headcount doesn't create service boundaries; business domains do.
Wonderful @gavincettolo .
This is one of the best explanations of “premature microservices” I’ve read in a while.
A lot of developers copy architectures from companies operating at completely different scales without realizing those companies earned that complexity over years of growth.
The modular monolith point is especially important. Clean boundaries inside a monolith give you most of the organizational benefits without immediately taking on distributed systems pain.
I’ve seen teams spend more time maintaining Kubernetes, service communication, and CI/CD pipelines than actually shipping product features.
“Start simple. Feel the pain. Split deliberately.” is probably the most valuable takeaway here.
Thanks a lot @healer_dev_44410c25f92d3c, really appreciate this thoughtful comment 🙏
You perfectly captured the core message of the article: architecture should solve current problems, not imitate someone else’s scale.
Too often teams adopt microservices because they look “modern”, then discover they’ve traded simplicity for operational overhead long before they actually needed to.
I’m glad the modular monolith point resonated with you. In many cases, strong boundaries, good domain separation, and disciplined engineering practices inside a monolith already provide most of the benefits people are chasing.
And yes, distributed systems complexity is real. Networking, observability, orchestration, CI/CD, resilience… all of that becomes part of the product whether you wanted it or not!
Really appreciate you taking the time to share your perspective.
Really solid article!
Over the last few years I’ve seen startups with 4–5 developers jump straight into Kubernetes, event buses, and a dozen microservices… only to spend half their sprint dealing with CI/CD pipelines and networking issues instead of shipping features.
The part about the “distributed monolith” hit hard because that’s exactly what happens when teams split domains too early.
That’s one of the most common patterns I see too.
A lot of teams adopt microservices because they feel “enterprise-ready,” but often they’re just introducing complexity for problems they don’t actually have yet.
A well-structured modular monolith already gives you most of the benefits without the operational overhead.
Exactly.
I think part of the issue is that many developers still associate “monolith” with “legacy spaghetti code,” when in reality a modular monolith can have very clean boundaries.
In my last project we split everything internally by domain:
auth
billing
catalog
notifications
Single deployment, but strict boundaries.
Debugging and onboarding became dramatically simpler.
That’s exactly the point I wanted to make.
Logical boundaries matter more than physical boundaries in the early stages.
If the codebase is well organized, extracting services later is relatively straightforward.
Doing the opposite is usually painful.
And a lot of teams underestimate the cognitive cost of microservices.
When implementing a single feature requires you to:
And most of the time, the actual traffic of the application doesn’t justify any of it.
Exactly, and that’s why I emphasized one key question in the article:
“What specific problem are we solving?”
If there’s no real issue around scaling, independent deployments, or failure isolation, microservices are probably adding more complexity than value.
It would be helpful to provide a title or caption for the summary table at the end of The Decision Framework.
Good suggestion, adding a caption/title would definitely make the framework easier to scan and reference quickly. I’ll probably update it with something like “When You Actually Need Microservices” or “Monolith vs Microservices Decision Matrix” to make the intent clearer at a glance.
Thanks for the feedback!
Done, thank you @the_aicoder
Smart to question the microservices hype: start simple, scale later. Do you prefer monoliths for speed or microservices for resilience, and why?
For most teams and products, I prefer starting with a monolith, specifically a modular monolith, because it optimizes for development speed, simplicity, and maintainability early on.
A well-structured monolith gives you:
Those advantages matter a lot when the product, requirements, and even the team structure are still evolving.
Microservices become valuable when resilience, independent scaling, or team autonomy become actual business constraints. For example, if different parts of the system have very different scaling needs, uptime requirements, or release cycles, then the operational complexity starts to pay for itself.
So for me it’s less “monolith vs microservices” and more:
Architecture should evolve with real pain points, not trends.
Well done @gavincettolo , great article!
I am curious to read the comments 🙂
Thank you @paolozero