Following the simplistic decomposition heuristic of having each service expose only a single method proved to be suboptimal for many reasons. First, it’s simply not possi‐ ble. Since the services have to work together, we were forced to expand their public interfaces with integration-related public methods. Second, we won the battle but lost

the war. Each service ended up being much simpler than the original design, however the resultant system became orders of magnitude more complex.

The goal of the microservices architecture is to produce a flexible system. Concen‐ trating the design efforts on a single component, but ignoring its interactions with the rest of the system, goes against the very definition of a system:

• A set of connected things or devices that operate together

• A set of computer equipment and programs used together for a particular purpose

Hence, a system cannot be built out of independent components. In a proper microservices-based system, however decoupled, the services still have to be integra‐ ted and communicate with each other. Let’s take a look at the interplay between the complexity of individual microservices and the complexity of the overarching system.