多層服務與系統複雜性
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開發以來，一直在構建和思考平臺架構。他堅定支援服務化架構，只是精準指出了當時這些架構中仍然缺失的關鍵部分。這篇隨筆至今讀來，不僅是亞馬遜在解決“平臺問題”時生活狀態的絕佳時間膠囊，也是對服務化架構本質的深刻洞察。