如上图所示，假设在一个Web系统中，Service A负责处理前端请求，Service B负责管理用户信息（包括姓名、性别、年龄等45个属性）。Service A每处理一个请求都需要向Service B查询用户姓名（200 bytes），而在一次请求中，Service B却返回了用户的所有信息（500 kb）。如果系统每秒处理2000次请求，每次请求消耗500 kb带宽，那么每秒消耗的总带宽会是1 Gb！如果Service B仅仅返回必须的姓名，那么同等条件下，每秒消耗的总带宽仅仅是400 kb。
此类问题就是所谓的stamp coupling，解决方法也很多，比如在请求中添加属性选择，使用GraphQL替代REST。相比于这些技术手段，更重要的是确定服务间通信所需的最小数据集，并在进行系统设计时将其作为一个重点关注的因素。
谬误4：网络是安全的
VPN、防火墙等的广泛使用，使得很多工程师在设计系统时忽略了“网络是不安全的”这一重要原则。特别是从单体架构演进到分布式架构以后，系统被攻击的概率将会大大增加。因此，在分布式系统中，每个服务都必须是安全的endpoint，这样才能确保任何未知或恶意的请求都被拦截掉。当然，安全是有代价的，这也是像微服务架构这类细服务粒度的系统，一次业务请求中调用链过长后性能极速下降的重要原因。
谬误5：网络拓扑一成不变
这里的网络拓扑指的是系统运行时所涉及到的网络设备，包括所有的路由器、防火墙、集线器、交换机等。很多工程师会假设网络拓扑是固定的，然而并非如此。
假设如下场景，为架构师的你在周一早上回到公司后，发现组内同事都在为系统中所有的服务间通信都在不断出现响应超时现象而抓狂，但奇怪的是周末并没有做服务变更。经过几个小时的攻关后，你发现周一凌晨2点时有过一次网络升级，而恰恰是这次“次要”的网络升级，推翻之前设计系统时的时延假设，从而触发了本次事故。
因此，软件工程师也需要与网络管理员时常联系，确保在每次网络升级前都明确网络拓扑的变更点，从而做出相应的调整。
谬误6：只有一个网络管理员
网络管理员往往不止有一个，特别是在“云”时代，数据中心分散在多个地域，理所当然也存在着多个局域网。运行在“云”上的系统很有可能跨越多个数据中心，因此工程师们应当感知各个数据中心的网络管理员对网络的相关操作，提前做出应对措施，避免出现因网络拓扑变更（谬误5：网络拓扑一成不变）而导致的服务通信超时，甚至触发服务熔断。
谬误7：通信成本为0
这里的通信成本并非指网络时延，而是指每增加一次服务间调用所导致的钱的花销。很多工程师在设计系统时常常忽视掉通信成本，大家都在鼓吹分布式架构相对了单体架构的优越性，却忘记了它带来的服务器、防火墙、网关等硬件的数量增加，这些都是白花花的银子。
因此，在进行系统设计时，我们也应该将硬件资源和网络拓扑纳入考虑因素。
谬误8：网络是同质的