Ever since cloud services became a thing, getting access to infrastructure has been a breeze. Before that, back in the days when companies were stuck managing their own data centers, everything was slow. You needed an entire infra team, approvals, business validations, and whatever limited resources were available. It was all a bottleneck. Then AWS showed up, and everything changed. Suddenly, developers had the power to spin up servers and services on their own. This also boosted the so-called micro-services architecture that was earlier prevalent in FAANG level companies.
But here’s the thing: while microservices are great in certain situations, they’re not always the right move for startups. A well-designed monolithic architecture can handle millions of users and scale with some good old’ design patterns like load balancing, shading or caching. In fact, a lot of SaaS companies — serving both SMBs and enterprise customers — are still running monoliths just fine. They scale as needed, no fuss. So, when do companies really actually need micro-services?
Here’s my take:
When Micro-services Make Sense
1. Too many cooks in the kitchen (aka engineers pushing to the same codebase): Imagine a team starts small — five engineers, a monolith, and a single Git repo. Everyone’s happy, pushing code to prod daily. Then, you grow to 50, maybe even 100 engineers. Suddenly, the team’s velocity slows down. One squad needs to revert something, and the rest of the team is stuck. Big features are fighting for deployment windows. This is where microservices help. You split the monolith into business-specific services, and teams can deploy independently without stepping on each other’s toes.
2. When parts of your system need to scale differently: Let’s say you have a set of APIs that’s getting hammered with traffic, while the rest of the system is cruising along just fine. That high-traffic API is now slowing down everything else — your app server, your database. By breaking those APIs into their own microservice, you can scale them separately and keep the rest of your system running smoothly.
3. Different SLAs for different parts of the app: This one’s kind of related to scaling, but it’s more about service-level agreements (SLAs). Some parts of your app might be mission-critical, while others aren’t as time-sensitive. You might need dedicated resources, monitoring, and faster response times for certain services. Splitting those into microservices makes sense so you can treat them differently.
Note: There are other reasons as well. I’ve just focused on these in this article.
The Trade-offs You Can’t Ignore
At first, the assumption is, “We’re building an architecture that can scale for future load.” But there’s a fundamental flaw with this thinking: scaling isn’t the only thing that happens with architecture. ARCHITECTURE EVOLVES! You start with certain assumptions, and as users begin interacting with your product, you learn from real-world use cases. You’ll need to redesign parts of your architecture, and that’s where things get tricky.
If your business logic is scattered across multiple microservices, changing things becomes a nightmare. As a startup, you need to move fast, pushing updates and features daily. But with a complex micro-services architecture, you’re sacrificing that feature velocity for some future scalability you may not even need.
For example, just to push a single feature, you could end up making 5 or 6 separate deployments across different services. And you have to be extra careful that deploying one service doesn’t accidentally break another. In theory, microservices should be independent, with each service using its own database and logic. But in practice — especially when you’re moving fast and pivoting often — you’ll end up with a tangled mess of API calls and interdependencies. Best practices fly out the window as you focus on speed, and the architecture can quickly become chaotic.
Then, there’s the matter of infrastructure costs and maintainability. Micro-services come with additional overhead:
- More app servers.
- More database servers.
- Logging and monitoring for all those services.
- Network costs for inter-service communication.
- Message queue costs and more.
Even if you’re okay with the higher infra costs in the early stages (before you have many customers), you’ll still need more engineers to maintain this complex setup. Sure, people will say that small teams of 10x engineers can manage large-scale microservices architectures, and that’s true. But here’s the catch: these 10x engineers are rare and expensive. You’d be incredibly lucky to even have one on your startup team, let alone enough to handle the extra workload.
So, What’s the Real Problem?
The problem isn’t that microservices are bad — they’re great when you need them. The issue is when people jump into microservices too soon.
The thought process is usually, “We’re building for future scale.” And while that sounds good, there’s more to it than scaling. Your architecture will evolve based on real-world use, and locking yourself into a complex setup too early can hurt your ability to move fast and adapt. For startups, speed is everything. You need to push features and react to feedback quickly. A monolith allows you to do that without all the extra baggage.
The Bottom Line
If you’re a startup, keep it simple. Build fast, iterate based on real user feedback, and let your architecture grow naturally as your needs evolve. A monolith will probably serve you just fine in the early days. When the time comes to break things into microservices, you’ll know. But don’t jump the gun — you’ll only slow yourself down, burn through cash, and add complexity where you don’t need it.
