Microservices Network Design

Conway’s law states that organizations design systems which mirror their own communication structure. It follows that companies which have an effective communication structure will have higher leverage than those who don’t. They will not duplicate work, teams leverage each other, they use feedback loops to improve, and can therefore adapt more quickly to changing circumstances to remain competitive.

E-commerce companies like Scalable Press are able to innovate by delegating tasks involved in product lifecycles and automating rules in the form of microservices. A microservices architecture style structures an application as a collection of services. Instead of your frontend browser or mobile app reaching out to a server running an entire monolith, it may be reaching out to several smaller servers, each running components that work together to make up your product experience.

Delegation requires that a frontend website is able to communicate with these tools, and that they are able to communicate with each other seamlessly. The frontend may pull a shopping cart from one service, search results from another, and coupons or deals from a third. Naturally, the work asked of these services will not scale equally. Customers may search dozens of times in a session. Coupons may be ignored because of page placement or lack of interest. Some microservices will be in high demand by customers, where other microservices will see only moderate or no growth.


Network design will affect how responsively the team is able to react to these changes in customer demand. The network design hinges on the way the proxy layer is set up. A proxy layer allows a single interface where web traffic can be split up and routed to the correct service. It also provides a mechanism for fault tolerance, so that if any server dies, the e-commerce site will still remain online.

Product managers perform a similar role. They use customer-driven metrics to make strategic decisions, then work with members of their team to knock out specific objectives. They choose which team member works on a given task based on the skills they have, and if someone is sick, tasks can be shifted toward others with similar skills.

Teams have specialized responsibilities because there is usually no need for them to know everything. If one person writes QE tests full time or several people write QE tests part time may make little difference in the amount of tests that get written, but the cost associated with onboarding or offboarding teammates will add up.

In the same way, if the proxy layer is set up such that a server must be running eight services to join the proxy pool, the proxy layer will require eight times as much effort to spin up another one, even if only one service is actually needed. In both cases, the ability to respond to rapid changes in demand relies on effective separation of responsibilities.


Product lifecycles are straightforward to understand. New trends appear, followed by a brief period of extreme hype. Enterprises that are able to identify these trends, reach customers, accept orders, and fulfill hyped products rapidly can capitalize on the limited opportunity, before interest wanes. Businesses that fail any of these steps will lose.

If there’s one key lesson buried in here, it isn’t how to break down responsibilities or who should be working on what. The main point is that a team that communicates effectively and which trusts one another will accomplish more than one who doesn’t. In a time when meeting in person is impossible, it’s easy to reinvent the wheel. Checking in with a few people before starting can give a competitive edge in getting a new idea online, by avoiding work that is already done.