Stop 20 · System DesignTopics · 7/15

Microservices vs Monolith

In short

Microservices sound grown-up, so beginners start with ten services and drown in network errors. Most products should start as a clean monolith, and split only when there's a real reason.

A monolith is one deployable application containing all your logic; microservices split functionality into independently deployable services — each with real trade-offs in complexity, team autonomy, and operational overhead.

The purple blob stands between one big crowded kitchen and a food court of separate stalls.

Think of it like this

Joint family kitchen vs food court

A joint family kitchen has one stove and one fridge, and everyone cooks together. Easy to share masala, but one gas leak stops every meal. A food court has separate stalls with their own kitchens. One closing doesn't stop the rest, but now you need billing, shared seating and coordination.

Watch it happen

One box or many?

Monolith

One codebase, one deploy, one database
Function calls and simple transactions
Whole app scales and fails together

Microservices

Many services, deployed independently
Network calls, retries, eventual consistency
Teams and parts scale separately

Start with a well-structured monolith. Split out a service when a team, a scaling need or a failure boundary clearly demands it.

The big ideas

What you need to know

A monolith isn't a mess

A modular monolith, with clear folders per domain, is fast to build, easy to debug and simple to deploy.

Microservices solve team problems

They shine when many teams must ship independently. For three developers, they're mostly overhead.

The network is unreliable

Every call between services can fail or be slow. You'll need timeouts, retries and tracing.

Database per service

Each service owns its data. Sharing one database between services quietly glues them back together.

See it in code

Walk through the code

1// Monolith: a function call. Fast, typed, one transaction.2const total = await pricing.calculate(cart);3 4// Microservice: a network call. Plan for failure.5const res = await fetch("http://pricing:4000/calculate", {6  method: "POST",7  headers: { "Content-Type": "application/json" },8  body: JSON.stringify(cart),9  signal: AbortSignal.timeout(800),10});11if (!res.ok) throw new Error(`pricing failed: ${res.status}`);12const { total: remoteTotal } = await res.json();

1/4Inside a monolith this is just a function call. It can't get lost on the network.

Same job, very different risk. The second version can time out, return errors, or succeed after you've already given up.

Save yourself the pain

Common mistakes

Oops

Splitting into microservices before you understand the domain.

Do this instead

You'll draw the boundaries wrong and pay with chatty services. Learn the domain inside a monolith first.

Oops

Building services that all read and write the same tables.

Do this instead

That's a distributed monolith: all the network pain, none of the independence. Give each service its own data.

Your mission

Find your seams

~25 min

Quick check

A team of 3 is building a new app with unclear requirements. What's a sensible starting architecture?

Go deeper

1List 3 advantages and 3 disadvantages of microservices versus a monolith.
2Understand most successful products start as a monolith and split out services only when there's a real reason to.
3Learn what problems microservices solve that a well-organized monolith often can't — independent scaling, independent deploys, team autonomy.