Key idea
Start with one service that does everything, organised inside into clear parts. Split a part out only when it needs something the rest doesn't: a different way of running, a different size, or a different release schedule.
Two ways to build the same app
A monolith is one program, deployed as one unit. The shop's pages, its API and its order logic all live in one codebase and ship together.
Services split the same app into several programs, each deployed on its own, that talk to each other over the network. The orders part becomes its own service with its own address.
Neither is modern or old-fashioned. They trade different costs.
What splitting costs
Every split turns a function call into a network request. That brings everything from the API module with it:
- Calls can fail. A request between services can time out or get an error, so each caller needs a plan for that.
- Contracts must hold. Change one service's API and every service calling it has to keep working, through every release.
- Debugging spreads out. One slow page can mean reading the logs of three services to find out which one was slow.
- More to run. Each service has its own settings, deploys, health and bill.
A small team pays all of that on day one, before it knows which parts of the app will grow.
What one service gives you
- One deploy. A change that touches pages and API ships at once, with no version mismatch between them.
- Refactoring is cheap. Moving code between parts is an edit, not a migration of a public contract.
- One log to read. A request's whole story is in one place.
The discipline is keeping the inside tidy: separate folders or modules for pages, API and orders, each calling the others through a few clear functions. That's often called a modular monolith, and it makes a later split straightforward.
When a part earns its own service
Split when a part genuinely differs from the rest:
- It runs differently. Slow work such as sending emails or resizing images shouldn't hold up a request. It moves to a background worker (lesson 2.1.3).
- It needs a different size or count. One heavy part shouldn't force every spherelet of the app onto a bigger shape (the CPU and memory size from lesson 1.2.1).
- It ships on a different schedule, usually because a different team owns it.
"It feels cleaner" isn't on the list.
Check yourself