Saying that a microservice is a micro-public interface is deceptively simple. It may sound as though limiting service interfaces to a single method would result in perfect microservices. Let’s see what will happen if we apply this naïve decomposition in practice.

Consider the backlog management service in Figure 14-3. Its public interface consists of eight public methods, and we want to apply the “one method per service” rule.

Figure 14-3. Naïve decomposition

Since these are well-behaved microservices, each encapsulates its database. No one service is allowed to access another service’s database directly; only through its public interface. But currently, there is no public interface for that. The services have to work together and synchronize the changes each service is applying. As a result, we need to expand the services’ interfaces to account for these integration-related concerns. Fur‐ thermore, when visualized, the integrations and data flow between the resultant serv‐ ices resemble a typical distributed big ball of mud, as shown in Figure 14-4.

Figure 14-4. Integration complexity

Paraphrasing Randy Shoup’s metaphor, by decomposing the system to such fine- grained services, we definitely minimized the services’ front doors. However, to implement the overarching system’s functionality, we had to add enormous “staff only” entrances to each service. Let’s see what we can learn from this example.