N-Tier Services and Systems Complexity

The lost Amazon essay, recovered twenty years late. Steve wrote it inside the company in November 2004 and made it briefly public in March 2006, where it lasted five days before being pulled at CTO Werner Vogels' request for naming the internal service architecture too plainly. It survived only in the version-control history of his old cabochon.com server. The essay turns on one question — do Amazon's internal data services (Customer Master, Order Master, Item Master and friends) reduce overall systems complexity, or just move it? — and answers, from inside an application team, that breaking up the databases solved a real problem (the “2-tier” problem of SQL wired into client code) but handed the bill to app developers, who lost the expressiveness of SQL and got a patchwork of hand-built object-oriented service calls in its place. Two running metaphors and nine deadpan footnotes do the rest.

It isn't a conversion story. Steve had been building and thinking about platforms since his MUD days in the early '90s, and the essay is firmly pro-service; it just pins down the piece those architectures were still missing. He lays out the two ways a service API fails its callers — forcing them to over-fetch a whole object graph, or burying service owners under a sprawl of chatty fine-grained calls — then points at the fix: “…the next logical step is to build a new query language that abstracts the APIs away for the clients.” That language is GraphQL, which Facebook shipped in 2012 to solve those exact two problems. He wrote it in 2004, when REST itself was barely understood.