Distributed Architectures are a lot like neural networks; all services that talk to each other need to share the I/O in and in a way that they can synchronize that information on the fly.
Since the API Pattern designed in the 1970’s for centralized architectures and NOT distributed architectures, it was never intended to be used in this way and creates an architectural cross-cutting concern when used in distributed services.
The original API pattern has a fatal flaw wherein it binds the communication logic to business logic. This flaw makes it so that communication cannot be shared without duplication of the I/O state. This issue is what is known as a ‘cross-cutting concern‘ . If you are using a distributed architecture, you will notice these issues increasingly as you scale.
The solution is what this article calls API Abstraction. To solve this inherent error in the pattern, one has to abstract the communication logic and data away from the business logic into a separate layer.