Every few months, this question pops up again in some team's Slack channel: should we be using microservices? Usually it starts because someone read an article about how a big tech company scaled to millions of users with microservices, or because a new hire on the team is used to working that way and suggests it during a planning meeting. And almost every time, the conversation turns into a debate that's less about the actual product and more about which approach sounds more "modern."
Neither approach is automatically the right one. The answer really depends on what's being built, how big the team is, and how much operational overhead the team is actually ready to take on. So instead of picking a side, it's worth walking through what each approach actually looks like in practice, where each one shines, and how to think about the decision without just following whatever's trending.
What is a monolith, really? A monolith is a single application that contains all the code: the user interface, business logic, and data access, all deployed together as one unit. When someone says "monolith" it sometimes sounds outdated, like something you'd only find in a legacy system nobody wants to touch. But a well-structured monolith is one of the fastest ways to build and ship a product, especially early on.
With a monolith, there's one thing to deploy and one place to debug. When something breaks, there's no need to figure out which of five different services is the culprit; it's one codebase, one set of logs, one running process. Testing is simpler too, since everything runs together and there's no need to mock out a dozen other services just to test one feature. This is a big part of why most early-stage startups and early SaaS products start out as monoliths. When a team is still figuring out what the product even is, keeping things simple allows it to move fast and change direction without a huge amount of rework.
Microservices flip that model around. Instead of one big application, the system is split into smaller, independent services, each one responsible for a specific piece of functionality, each deployed separately, and often owned by a different team. A payments service, a notifications service, a user-management service, and so on, all talking to each other over the network instead of through direct function calls in the same codebase.
The appeal here is real. Since each service is independent, teams can scale just the piece that needs it: if the notifications service is getting hammered with traffic, that service can be scaled alone instead of scaling the whole application. Teams can release their own services on their own schedule instead of waiting for one big deployment. And if one service goes down, ideally the rest of the system keeps running instead of everything failing at once. There's also more flexibility in terms of tech choices: one team could use Node, another could use Python, based on what fits their service best.
None of that comes for free, though. Once logic is split across services, everything that used to be a simple function call becomes a network request, which means it can fail, time out, or arrive out of order. Debugging turns into piecing together logs from multiple services just to trace a single user action from start to finish, which is a completely different skill than stepping through one codebase in a debugger.
Monitoring and observability also become a bigger deal. With one application, basic logging is often enough. With ten services, proper distributed tracing, centralized logging, and dashboards become necessary, or hours get spent trying to figure out which service actually caused a slowdown. Data consistency gets trickier too: in a monolith, a single database transaction can update multiple things atomically. Across services, teams are often dealing with eventual consistency, which means designing around the fact that different parts of the system might be slightly out of sync for a moment. And all of this infrastructure, the extra services, the message queues, the monitoring tools, adds up in cloud costs and DevOps time that a monolith simply doesn't need.
A monolith makes the most sense when a team is still small, the product is still evolving, and there isn't yet a specific scaling bottleneck to solve. When an engineering team is only five people, running five microservices means each person is basically responsible for maintaining their own distributed system on top of building features, which usually slows things down rather than speeding them up.
Microservices start to earn their complexity once there are clear signals: one part of the system genuinely needs to scale independently, different teams keep stepping on each other's toes working in the same codebase, or a specific service needs a different release cycle than the rest of the app. In those cases, splitting things out solves a real problem instead of just following a trend.
A useful middle ground is the idea of a modular monolith: one deployable application, but internally organized into clear, well-separated modules with defined boundaries. This keeps the simplicity of one deployment and one codebase, while making it much easier to pull a module out into its own service later, if and when that's actually needed.
When deploying on AWS, Azure, or Google Cloud, this decision also affects how much cloud-native complexity gets taken on. Microservices usually go hand in hand with containers and Kubernetes, which are powerful tools, but they come with their own learning curve: networking between pods, service discovery, scaling policies, and so on. A monolith can often run comfortably on a much simpler setup, which means less time spent managing infrastructure and more time spent building the actual product. It's worth being honest about whether a team needs that complexity yet, or whether it's being adopted because it looks good on paper.
So, which one should you choose? There's no universally correct answer here. It depends on team size, how mature the product is, what the actual scaling needs are, and how much operational capability exists to support a more complex architecture. In most cases, a well-designed monolith is the fastest way to deliver real value in the early stages of a product, and splitting things into services is a decision worth making deliberately, once there's a concrete reason to do it, not just because it's the direction everyone else seems to be heading.
