Microservices

What are Microservices?

A microservice architecture splits an application into a set of small programs that each own one job and one slice of data, and that talk to each other over the network. Billing is a service. Notifications is a service. Search is a service. Each can be deployed, scaled, and rewritten without touching the others, at least in theory.

The alternative, a monolith, keeps everything in one codebase and one deployable unit. Calls between parts of the system are ordinary function calls that either succeed or throw. In a microservice system those same calls cross a network, which means they can also be slow, arrive twice, or vanish entirely. That single change is the source of nearly every benefit and every cost of the approach.

Microservices became popular at companies with hundreds of engineers, where the real bottleneck was coordination: fifty people trying to merge into one repository and ship one deploy. Splitting the system let teams ship independently. That is an organizational fix first and a technical one second, which is exactly why it so often disappoints small teams who adopt it for the technology.

Microservices compared to a monolith

Dimension	Monolith	Microservices
Deployment	One unit, one pipeline	Many units, many pipelines
Failure mode	Everything fails together	Partial failures you must handle explicitly
Debugging	One stack trace	Traces across several services and logs
Scaling	Scale the whole app	Scale only the hot service

Nothing in that table says one is better. It says the costs move. With microservices you trade code complexity for operational complexity, and operations is the thing a five-person team has least capacity to absorb.

Why microservices matter for startups

The useful founder question is not whether microservices are good engineering. It is whether your bottleneck is coordination. With three engineers in one repository, coordination is a conversation. Splitting into eight services to solve it adds deployment pipelines, service discovery, monitoring, and a class of bug that only appears in production.

There is a version of this that does make sense early. If one part of your system has genuinely different requirements, such as a video transcoding job that needs heavy machines or a scraper that must be restarted constantly, pulling that one piece out is sensible. That is not adopting microservices. It is extracting a service, and it costs a fraction as much.

The decision this changes: how much of your limited engineering time goes into infrastructure instead of the product customers pay for. Early on, almost all of it should go to the product.

Microservices in practice

Imagine a three-person team building a scheduling product. They start with a single application and one database. Six months in, PDF generation for invoices starts using so much memory that it occasionally takes down the web server during peak hours.

They pull PDF generation into its own small service with a queue in front of it, running on a separate instance sized for the job. The main application stays a monolith. Total new infrastructure: one service, one queue, one dashboard. The crash goes away, and nobody has to learn service meshes or distributed tracing.

Two years and eleven engineers later, the monolith has become the coordination bottleneck the theory describes, and splitting further starts to pay for itself. The order matters: they split when the pain arrived, not in anticipation of it.

When splitting actually pays off

A few honest signals that a split is earning its keep. Different parts of the system need very different hardware or scaling patterns. Separate teams are blocking each other on deploys. One component has a failure mode you want isolated from everything else. A piece of the system is being rewritten in a different language for a good reason. If none of those apply, the monolith with clean internal module boundaries gets you most of the organizational benefit at a fraction of the operational cost, and it leaves the door open to split later.

Common mistakes

• Starting with microservices on day one. You do not yet know where the boundaries are, and wrong boundaries are far more expensive to fix across services than inside one codebase.
• Splitting by technical layer. A database service and a logic service still deploy together in practice. Split by business capability instead.
• Sharing one database between services. If two services write the same tables, you have a monolith with extra network hops and none of the independence.
• Skipping observability. Without centralized logs and request tracing, a distributed bug turns into a multi-day investigation.
• Ignoring failure between services. Every network call needs a timeout and a plan for what happens when the other side is down.

Related concepts

Services talk to each other through some form of API, so the quality of those contracts largely determines whether a split helps or hurts. Running many independently deployed services demands real DevOps practice, including automated pipelines and monitoring. The usual motivation is scalability, though a well built monolith scales further than most teams expect, and for an early minimum viable product the simpler architecture almost always ships sooner.