When to Merge Services Back

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.

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.

Quick check: Which signal suggests two services might be better merged?

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