Y

You nod. It sounds right. Netflix uses microservices. Gojek uses microservices. Why wouldn't you?

Here's what the diagram probably doesn't show: the operational complexity, the new failure modes, and the three to six months of engineering time you're about to spend not shipping product features. Microservices are a real architectural pattern with real benefits. They're also one of the most reliably over-applied ideas in startup engineering. Understanding the difference will save you from one of the more expensive mistakes a founding team can make.

What a microservice actually is

A traditional application what engineers call a monolith runs as a single deployable unit. Your user management, your payments logic, your notifications, your reporting: all packaged together, deployed together, scaled together.

A microservice is the opposite approach. Each distinct function of your product becomes its own independent service. User management runs as one service. Payments runs as another. Notifications runs as a third. They communicate with each other over a network, usually via APIs.

The appeal is real. Each service can be deployed independently, which means a bug in the notifications service doesn't require redeploying your entire payments system. Each service can be scaled independently, so if your image-processing service is under load, you scale that specific service rather than everything. Different services can be written in different languages by different teams.

That's the theory. The practice is messier.

Why your developers are probably recommending this

Two legitimate reasons and one less legitimate one.

The legitimate reasons: your monolith has grown to the point where a single team can't understand all of it, or you have genuinely independent business domains being awkwardly forced to share a codebase. At that scale, the organisational benefits of microservices separate teams owning separate services start to outweigh the costs.

The less legitimate reason: microservices are fashionable. They're what the large tech companies use, so they feel like the obviously correct approach. But Gojek didn't start with microservices. Tokopedia didn't start with microservices. They reached the scale at which a monolith became a genuine obstacle, then made the switch. The order of operations matters.

If your team is fewer than fifteen engineers and your product is under a few years old, the honest answer is: you probably don't have the scale that microservices are designed to solve.

What nobody tells you about the operational cost

Every service boundary you add creates a new failure mode.

In a monolith, when your payments code calls your user management code, that's a function call. It's fast, it's in-process, it either succeeds or it doesn't. In a microservice architecture, that same interaction crosses a network. Networks are unreliable. The payments service calls the user service, the user service is temporarily slow, now you have a latency problem that cascades. You need retry logic, circuit breakers, timeouts, fallback behaviour all things your monolith got for free.

You also need to deploy, monitor, and maintain multiple services independently. Each one needs its own CI/CD pipeline, its own logging, its own alerting. A five-engineer team that previously managed one deployment now manages eight. The overhead per engineer goes up substantially.

Testing gets harder. A feature that touches three services requires integration tests across three services. Local development gets harder developers need to run multiple services on their machine, or connect to shared development environments that have their own stability problems.

None of this is a reason to never use microservices. It's a reason to understand the full cost before you commit.

The part most founders get wrong

Conflating "we have a scaling problem" with "we need microservices."

These are different problems. If your system is slow under load, the first questions should be: are your database queries optimised? Do you have caching in place? Have you profiled where the bottleneck actually is? Most early-stage scaling problems are solved at the database layer or with caching not by splitting the application into services. The [→ Read: What Is Software Architecture?] guide covers the broader decision space here.

The other version of this mistake: splitting prematurely, before the team understands the domain well enough to draw the service boundaries correctly. Microservice boundaries should reflect real business boundaries payments is genuinely different from notifications. If you split too early, you'll draw lines in the wrong places, discover this six months later, and face a painful re-merge or an even more painful refactor. Bad service boundaries are worse than a well-structured monolith.

The question to ask your team isn't "should we use microservices?" It's "what specific problem are we trying to solve, and is this the most direct solution?" The [→ Read: the honest decision framework] goes deep on that exact question.

Real-world example

A logistics startup in Indonesia, twelve engineers, two years into their product. Their operations platform handled route optimisation, driver management, package tracking, and customer notifications all in a single Rails monolith.

The CTO proposed splitting into microservices. The reasoning: the system was getting complex, and different parts of it were changing at different rates. Both true.

What they did instead, after pressure-testing the assumption: a modular monolith. They reorganised the code into well-separated modules one for routing logic, one for driver management, one for tracking, one for notifications each with clean interfaces, deployed as a single unit. Developers could work on routing without touching notifications. The codebase became navigable again. Deployment stayed simple.

Eighteen months later, with thirty engineers and genuine load on the tracking service specifically, they extracted that one service. One extraction, on a known boundary, with clear justification. Not eight services at once based on a diagram drawn at the start.

FAQ

Q: What's the difference between a microservice and a monolith?

A: A monolith is a single application that contains all your business logic, deployed as one unit. A microservice architecture splits that logic into multiple independent services that communicate over a network. Neither is inherently better the right choice depends on your team size, product maturity, and the specific problems you're trying to solve.

Q: What is a microservice in simple terms?

A: It's one small, focused application that does one thing like handling payments or sending notifications and exposes an API so other parts of your system can use it. The idea is that small, independent pieces are easier to change and scale than one large, interconnected piece.

Q: When should a startup consider microservices?

A: When your team is large enough typically 15 or more engineers that multiple teams need to work on different parts of the system without blocking each other, or when one part of your system has radically different scaling requirements than the rest. Not before either of those conditions is genuinely true.

Q: Are microservices faster than a monolith?

A: Not automatically. A well-optimised monolith will often outperform a naively implemented microservice architecture because it avoids network overhead between services. Microservices can enable better scaling of specific components, but that's a different thing from raw performance.

Q: What is the risk of splitting into microservices too early?

A: You'll spend months on infrastructure that doesn't add user value, draw service boundaries that turn out to be wrong, and create operational complexity your team isn't ready to manage. Many startups that split early end up re-merging services or living with the consequences of bad boundaries for years.

The honest version of the microservices conversation is this: they solve real problems at scale. They create real problems before you have scale. Knowing which situation you're in is most of the decision.

If your team is pushing for this and you're not sure the timing is right, that's worth an independent architecture review before you commit the next six months to it.