The architecture in Figure 1 is probably still the most common approach taken by small- to medium-scale sites being developed and maintained by small teams, and it can perform very well. When the application has to scale in terms of request volume, and the engineering processes have to scale in terms of team size and organization, the next step is often to begin decomposing the service API implementations into more granular pieces: the microservices approach.
This model quickly introduces more connection paths into the flow of traffic on the back end, as it is usually inevitable that individual services will have to communicate among themselves. Figure 2 shows one such scenario.
Figure 2. Connection distribution in a microservices model.
In this scenario, the client finalizes an order, which requires the Orders service to first verify the client authentication and fetch user properties from the Users service, and then contacts the Shipping service to schedule delivery. Since the lifetime of each connection is shorter and caching can reduce the number of requests, comparing this to the monolithic approach is not as simple as counting open connections. But, clearly, one impact of using HTTP as the bus for traffic between microservices is more TCP/IP overhead.
One impact of using HTTP as the bus for traffic between microservices is more TCP/IP overhead. Mark Betz
Another impact comes from the nature of the Internet Protocol itself: In order to get a packet of data to a port on a particular server, you need to know the server's network address before connecting. The reason for this is to increase infrastructural rigidity by requiring servers to have known addresses, a problem that is difficult to reconcile with performance and durability enhancements like autoscaling and failover.
The alternative, and a much more flexible approach, is Service Discovery, which, in a nutshell, simply means that each server reports its network address to some central repository of system state that can be read by internal clients. This is the mechanism of choice for container clustering platforms like Kubernetes and Docker Swarm. It's reliable, but it is a little bit intrusive, as each service implementation must know how to interact with the service discovery framework as well as with the other services in the cluster.
