A service architecture can end up slower to change, harder to operate, and less reliable than the single large system it replaced, and it can cost more to run while doing it. This is rarely the work of a careless team.

How many decisions does it take to reach that point?

It rarely takes a single bad one. The path to such a situation is built from individually sound choices, a clean separation here, an independent deployment there, a new service each time a part of the system felt distinct enough to stand on its own. Those reasonable steps accumulate into an arrangement no one would have chosen on purpose, and the problems that emerge look like a catalog of separate mistakes even though nearly all of them trace back to one early decision about how to break a system.

At a basic level, a service is a part of a system that can be deployed on its own and controls its own data. This means it does not reach into any other service’s database to do its work. It also talks to other services over a network. Inside a single program, one function calling another takes a few nanoseconds and either returns an answer or raises an error. The same call across a service boundary can take a few milliseconds, and it can also time out or succeed halfway and leave things in an odd state. Almost every anti-pattern below emerges from this one problem.

In this article, we will look at some of the most important anti-patterns in service architecture, how they happen, and how they can be avoided.