API guide
Monolith or microservices?
Microservices solve a specific problem: many teams needing to change and release parts of a system independently. If you do not have that problem, they mostly add cost. A well-structured monolith is often the better first answer.
Start withA modular monolith
Split whenTeams block each other
For legacyStrangler pattern
AvoidThe distributed monolith
Honest comparison
| Modular monolith | Microservices | |
|---|---|---|
| Best for | One or a few teams, a product still taking shape | Many teams, parts with very different scale or release needs |
| Deploy | One unit, simple | Many units, needs a platform and automation |
| Data | One database, simple transactions | A database per service, harder consistency |
| Failure | In-process calls rarely fail | Every network call can fail and must be handled |
| Cost to run | Lower | Higher: platform, monitoring, more infrastructure |
Signs you should split a service out
- Teams wait on each other to release.
- One part needs to scale very differently from the rest.
- One part changes daily while the rest is stable.
- A clear business boundary exists, with its own data.
Signs you split too early
- Every feature needs changes in several services at once.
- Services share a database.
- You cannot test anything without starting everything.
Modernising a legacy system
- Put an API or gateway in front of the legacy system.
- Build new capabilities as separate services behind the same front.
- Move existing features out one at a time, routing traffic to the new version.
- Retire the old parts as they empty out. This is called the strangler pattern.
More API guides: API design and gateway · Event-driven integration · API security · API FAQ · Use case: partner APIs
Untangling integrations, or opening APIs to partners?
Tell us which systems need to talk, who will call your APIs, and what breaks today. We will come back with a plain view of the right structure, what to change first, and what to leave alone.