N-Tier Services and Systems Complexity — Steve Yegge
Skip to content
Editor's note · 2026
Written inside Amazon in November 2004 and briefly made public in March 2006, this essay stayed up for five days before being removed at Amazon CTO Werner Vogels' request — it described the company's internal data-service architecture (Customer Master, Order Master, Item Master) in more candour than Amazon was comfortable with at the time. It was long thought lost: it predated the Wayback Machine's first crawl of the blog and never made it into any public archive. It was recovered in June 2026 from the original cabochon.com CVS repository, where the deleted file survived in version-control history — the removal commit message reads, simply, “removed at Werner Vogels' request.” The architecture it describes has since been retired. What follows is a lightly tightened director's cut: trimmed by deletion only, never rewritten, so every word is Steve's. The complete original is preserved unedited in the archive.
As usual, this is an opinion-filled essay, with my own wacky<br>outlook on things at Amazon, and plenty of half-baked assertions<br>thrown in.
It's not easy to write about multi-tier architectures. You can spend<br>months writing a book, perhaps one with Friendly<br>Martians on the cover, or you can take a few cheap pot shots and<br>get back to the business of bouncing your servers. I chose the latter.
Today's essay is mostly about the following question, so before you<br>read on, ask yourself what you think the answer is:
Do Amazon's internal data services<br>and their corresponding object-oriented APIs<br>reduce or increase our overall systems complexity?
I'm writing this editorial because, to be quite honest, I thought the<br>answer was patently obvious: that services have obviously increased<br>our overall systems complexity.
But I've heard a few smart people suggest that the whole point of<br>services was to reduce our complexity. They say that the services<br>will hide the complexity of our code behind "well-defined interfaces".<br>It's become a company-wide slogan. Everything will supposedly become<br>easier to understand and maintain, and as a result, our quality<br>measures (availability, data integrity, flexibility) will finally<br>start to improve. Or so the theory goes.
I'm coming at this from the perspective of an app developer,<br>having been in an app group — specifically, Customer Service<br>Apps — for the past four years. We certainly don't see it that<br>way. I think the majority of development at Amazon is done by<br>application groups who are trying to support business objectives,<br>rather than by infrastructure groups who support or monitor the app<br>developers.
So the level of difficulty required in order to produce<br>applications here is a pretty important topic.
Why Services?
So why did we launch Services, anyway? Anyone remember? By<br>Services, I mean the big services like Customer Master Service (CMS),<br>Order Master Service (OMS), Item Master Service (IMS), Customer<br>Account Management Plus Something (CAMPS), and the like. These ideas<br>got started back in the Dark Ages of Amazon, in early 1997 or so, and<br>the implementations were finished, by and large, by 2007. (Written in 2004 — past tense, about a date three years in the future.)
If you weren't around here in 1997, you might surmise that we launched<br>services to reduce our systems complexity. That's not why we did it,<br>though.
We launched services because of a fundamental problem with our code<br>organization called the 2-tier problem. 2-tier is the name<br>we give to systems in which SQL is embedded in client code. It's<br>pretty much that simple.
Hypothetical Example
I'll use a running example, customer hair color, to illustrate why we<br>needed services.
Let's say you have a pressing business need to be able to look up<br>customers by hair color. You have a database with customer<br>information in it, and one of those bits of information is their hair<br>color. Someone wants to send out a promotional mailing to everyone<br>with red hair, so you write yourself a script that includes a snippet<br>of SQL that might look something like this:
SELECT customer_name FROM customers WHERE hair_color="red"
Easy! No matter what language you use to make this query, you'll get<br>back a list of names of customers who have red hair. As part of the<br>configuration for this code, you need to specify which database to<br>connect to, a username, and a password, all conveniently embedded in<br>your code.1
Now let's suppose that some percentage of our red-headed customers<br>reply to the promotional mail and say "hey, my promotion code didn't<br>work." This rarely happens in practice, of course.2 But when it does, we get a bunch of<br>contacts, and CS reps need to investigate. The reps will probably<br>need to look up a customer's order to see what happened.
Unfortunately, our customers aren't always as clued-in as we'd like<br>them to be, so the most information they might be able to offer the CS<br>rep is: "Well, um, I have red hair." So...