# When to Merge Services Back — Monolith vs Microservices

Source: https://www.skillbyai.com/en/monolith-microservices/g-reverse

> Recognise when consolidating services is the right move.

## Consolidation is a valid decision

Sometimes the right move is fewer services. Signs: services that are always changed and deployed together; very chatty pairs that make dozens of calls per user action; more services than the team can operate (several services per engineer); high cloud and tooling costs for little traffic; and incidents dominated by network failures between your own services. A widely discussed example is Amazon Prime Video's 2023 engineering write-up, in which a team moved a video-quality monitoring tool from a distributed serverless design to a single process, reporting infrastructure cost reductions of about 90% for that workload. The lesson is not "microservices are bad" but that architecture should follow the workload and the team. Merging follows the same careful steps as extracting: introduce an internal API, move code into one deployable, consolidate data, and delete the old service.

## Signals that a merge may help

Two or more strong signals for the same pair of services justify a closer look.

```text
signal                                                 measure it with
-----------------------------------------------------  ------------------------------
services A and B deploy together > 80% of the time     deploy history
one user action causes > 20 calls between A and B      traces
features almost always change both A and B             git history / PRs
the team owns more services than engineers             service catalogue
incidents caused by A<->B network issues               postmortems
infra cost per request far above the monolith baseline cost reports
```

## Optimise for the team you have

An architecture designed for 200 engineers is a burden for 15. Revisit boundaries when the team or product changes, in either direction.

**Quiz:** Which signal suggests two services might be better merged?

- [ ] They are owned by different teams with different release schedules
- [ ] They have different scaling needs
- [x] They are almost always changed and deployed together and call each other constantly
- [ ] They use different databases suited to their data

*Answer:* They are almost always changed and deployed together and call each other constantly. Lockstep changes and chattiness indicate the boundary between them is in the wrong place.