多层服务与系统复杂性
Steve Yegge在2004年于亚马逊内部撰写了一篇论文，探讨内部数据服务是否真正降低了系统复杂性，还是仅仅转移了复杂性。该文于2006年短暂公开后被撤回，因其直白描述了内部架构。Yegge指出了服务API的两种失败模式，并预言需要一种新的查询语言，八年后Facebook的GraphQL实现了这一构想。
2004年11月，Steve Yegge在亚马逊内部撰写了一篇题为“N层服务与系统复杂性”的论文。这篇论文最初于2006年3月在“Drunken Blog Rants”上公开发布，但仅五天后就因CTO Werner Vogels的要求被撤下，原因是Yegge过于直白地描述了内部服务架构。幸运的是，该文保存在Yegge旧服务器cabochon.com的版本控制历史中，二十年后得以重见天日。
论文的核心问题简洁而深刻：亚马逊的内部数据服务（如客户主数据、订单主数据、商品主数据等）究竟是减少了整体系统的复杂性，还是仅仅将其转移到了别处？从应用开发团队的角度出发，Yegge给出了明确的答案：拆分数据库确实解决了“两层”问题，即SQL直接嵌入客户端代码导致的紧耦合，但代价是应用开发者失去了SQL的表达力，取而代之的是一堆手工构建的面向对象服务调用。
Yegge运用两个生动的比喻和九个一本正经的脚注来阐述观点。他指出服务API容易陷入两种失败模式：一是强制调用者过度获取整个对象图（over-fetching），二是服务拥有者被淹没在大量细粒度、频繁调用的API中（chatty fine-grained calls）。针对这些问题，Yegge预见到下一步逻辑是构建一种新的查询语言，为客户端抽象掉这些服务API。这正是GraphQL的核心理念——Facebook在2012年发布的GraphQL恰好解决了Yegge八年前指出的这两个问题。
这篇论文并非一时兴起的转变之作。Yegge自90年代初从事MUD开发以来，一直在构建和思考平台架构。他坚定支持服务化架构，只是精准指出了当时这些架构中仍然缺失的关键部分。这篇随笔至今读来，不仅是亚马逊在解决“平台问题”时生活状态的绝佳时间胶囊，也是对服务化架构本质的深刻洞察。