One body or many? Monoliths and microservices
Before splitting software into many humans, ask whether you need more than one. Many successful systems are a single, capable person — a monolith — and that's fine.
The monolith: one person doing everything
Imagine a small corner shop run by one owner. They take orders, cook, collect money, clean and do the accounts.
- Simple — one person to manage, no coordination.
- Fast to start — no hiring, no meetings.
- Everything shares one brain and one memory — easy to keep consistent.
In software, a monolith is one deployable application containing all features, usually with one database.
Where the single person struggles
As the shop grows, the owner hits limits:
| Human problem | Software symptom |
|---|---|
| Can't be in two places at once | Can't scale one busy feature without scaling everything |
| A cold stops the whole shop | One bug or crash takes down every feature |
| Learning a new skill means relearning everything | Every change needs testing and deploying the whole app |
| Too many things to remember | Codebase becomes hard to understand |
| Only one person can work on it at a time | Many developers step on each other's changes |
Microservices: a team of specialists
Now the shop becomes a café with a waiter, a chef, a cashier and a delivery rider. Each person:
- Has one clear job.
- Has their own memory (the chef knows recipes; the cashier knows the till).
- Communicates with others in agreed ways (order tickets, receipts).
- Can be replaced, trained or doubled without changing the others — hire a second chef for Friday nights.
That is a microservice architecture: independent services, each owning a business capability and its data, communicating over well-defined interfaces.
Hiring has costs
A team isn't free. Every new "human" adds:
- Communication overhead — messages can be delayed, lost or misunderstood (network failures, latency).
- Coordination — who does what when an order is cancelled halfway?
- Duplication — each person needs their own tools and records.
- Observability needs — finding out who dropped the order is harder in a team of ten.
A team of ten specialists running a stall that serves five customers a day is wasteful. Splitting too early is one of the most common architecture mistakes.
When to split
| Signal | What it means |
|---|---|
| One part of the system is far busier than the rest | That part deserves its own human so it can scale alone |
| Different parts change at very different speeds | Separate them so fast-changing parts can deploy independently |
| Multiple teams work on the system | Give each team their own humans to own |
| One failure keeps taking everything down | Isolate the fragile part |
| Different parts need different technology or security | Separate bodies, separate rules |
A practical path many teams follow: start as a well-organised single person (a modular monolith, with clear body parts inside), and split off humans when one of the signals above appears. Clear modules make splitting easy later — the body parts already have boundaries.
The rule of one job
The most important design rule for a microservice is the one we use for people in a healthy team: one clear job, owned completely. "The Cashier handles payments" is a good service. "The Helper does whatever's needed" is a recipe for confusion.
Microservices are a trade: you gain independent scaling, deployment and failure isolation, and you pay with communication and coordination. Choose the trade deliberately.
Senior Full-Stack Engineer · AI & AWS. I design and build serverless systems on AWS — and love explaining them simply.