How Amazon Actually Works

Loading a single Amazon.com product page can involve requests fanning out to more than 150 separate internal services, several layers deep, each one expected to respond within its own strict time budget regardless of how much internal complexity it's hiding. That number alone says a lot about how differently Amazon's engineering culture treats the word "architecture" compared to most companies not as a single system, but as an enormous, decentralized economy of small, independently owned services that happen to cooperate.

This article traces how that came to be: an internal memo, issued around 2002, that quietly reshaped Amazon's entire engineering organization and eventually gave rise to AWS itself, and Dynamo, the distributed database Amazon built specifically to guarantee your shopping cart keeps working even while parts of its own infrastructure are actively failing. Amazon's CTO, Werner Vogels, has written about several of these systems directly on his own engineering blog, and Amazon's own published Dynamo paper remains one of the most influential documents in distributed systems.

A Company That Outgrew Sharing Its Own Database

A retrospective on API Evangelist tells the origin story through an unlikely source: a rant, accidentally posted publicly by a Google engineer named Steve Yegge, describing his own six years working at Amazon beforehand. Yegge recalled that sometime around 2002, Jeff Bezos issued an internal mandate that would reshape the entire company: all teams would henceforth expose their data and functionality exclusively through service interfaces.

A breakdown on High Scalability explains the actual pain this was responding to: Amazon's databases had become a shared resource that made it genuinely hard to scale the business out, and both the front-end and back-end were held back because they were shared by too many different teams and processes at once. A newer piece on AWS Tip puts the everyday symptom of this plainly: teams were stepping on each other constantly, and a bug in the recommendation engine could take down the entire checkout flow, because there was no real separation keeping one team's mistake contained to their own piece of the system.

A shared family kitchen where five different people are all trying to cook five completely different meals on the same two burners at the same time nobody can really plan their own dish properly, because everyone's plans are quietly tangled up with everyone else's, and one person burning their sauce can end up delaying dinner for the whole house. Amazon's early shared-database architecture had exactly that structural problem, just at company scale.

The Rules Themselves Were Deliberately Uncomfortable

A more recent breakdown on Biplus's blog lays out the mandate's actual, specific rules: every team must expose their data and functionality only through service interfaces, teams may only communicate through those interfaces, no other form of communication is allowed at all no direct database access, no shared memory, no back-door shortcuts of any kind and critically, every single service interface had to be designed as though it might eventually be exposed to developers outside the company entirely.

The same AWS Tip piece adds the organizational rule that came bundled with this technical one: teams had to be small enough to be fed with two pizzas the now-famous "two-pizza team" principle deliberately keeping the number of people behind any one service small enough that coordination overhead couldn't quietly creep back in through the org chart, even after the technical barriers were already in place.

A country that decides every single government office must communicate with every other office only through official, standardized paperwork no hallway conversations, no personal favors, no informal side deals specifically because informal shortcuts are exactly what let inconsistency and hidden dependencies quietly build up over time. Amazon's mandate was that same instinct, applied deliberately and uncomfortably to its own engineering organization.

Before the mandate:
  Team A → reaches directly into a shared database
  Team B → reaches directly into that same shared database
  → changes in one team's logic risk silently breaking another team's code
 
After the mandate:
  Team A → owns its own data, exposes it only via a defined service interface
  Team B → can only ever call that interface, never touch the data directly
  → Team A can change its internals freely, as long as the interface holds

Why "Externalizable by Design" Quietly Became AWS

Here's the detail that turns this from an interesting internal reorg story into something that reshaped the entire cloud computing industry. The same Biplus retrospective points out the mandate's least obvious, most consequential rule: every service interface had to be designed as though it could someday be exposed to the outside world, regardless of whether that was ever actually the current plan. A related piece on the same topic makes the connection explicit: the architectural principles the mandate enforced standardized interfaces, service autonomy, and interfaces built with outside use in mind from day one became the direct foundation for AWS's own service-oriented approach to cloud infrastructure.

A construction company that requires every internal tool, form, and process to be documented and packaged as though a completely separate company might need to license and use it someday years later, when the company decides to actually start renting out that tooling to outside clients, almost none of the underlying work has to be redone, because it was quietly built with that possibility in mind from the very beginning. Amazon wasn't necessarily planning to become a cloud computing company back in 2002. But the discipline of designing every internal service as though it might need to survive outside scrutiny meant that when the opportunity to become one did arrive, the foundation was already largely there.

Why a Shopping Cart Can Never Be Allowed to Say No

This next part of the story addresses a genuinely different kind of problem: once you've split everything into independent services, how do you make sure the data underneath them stays available, even while parts of the actual physical infrastructure are failing? Amazon's own 2007 paper on the subject, described directly by CTO Werner Vogels on his blog All Things Distributed, states the requirement in strikingly absolute terms: customers should be able to view and add items to their shopping cart even if disks are failing, network routes are flapping, or data centers are being destroyed by tornadoes.

The same post explains why this requirement broke from conventional database thinking: traditional relational databases are excellent at maintaining strict consistency, but that same strictness works against you when the priority is uninterrupted availability under real-world, ongoing failure conditions. The resulting system, called Dynamo, was built explicitly as a key-value store rather than a relational database, deliberately trading away some forms of strict consistency in exchange for near-constant availability, even during significant infrastructure trouble.

An emergency room that's built around a simple, absolute rule: never turn away a patient, under any circumstances, even during a power outage, even during a supply shortage, even if it means the paperwork gets slightly out of order and needs sorting out properly later the priority is keeping the doors open no matter what, and cleaning up any resulting inconsistency afterward, rather than ever risking turning someone away at the door. Dynamo was built around that exact same priority for a shopping cart: keep accepting the request, no matter what's failing behind the scenes, and reconcile any resulting inconsistency afterward rather than ever risking rejecting the customer's action outright.

Traditional relational database priority:
  Strict consistency first → availability may be sacrificed during failures
 
Dynamo's priority:
  Availability first, even during real infrastructure failures
  → Accept the write (add to cart) almost no matter what
  → Reconcile any resulting inconsistency after the fact

A Call Graph Deeper Than Most Engineers Ever See

Here's a detail that shows just how far this service-oriented philosophy actually extended in practice. The same Vogels post describes a typical page request on Amazon's e-commerce site as requiring the rendering engine to construct its response by sending requests to over 150 services and because those services often have their own dependencies on further services, the resulting call graph frequently runs more than one level deep. A breakdown on System Design Codex adds a critical constraint layered on top of this: to maintain a good user experience, each individual service has to honor its own specific Service Level Agreement in terms of response time and availability, regardless of how many other services it might itself be depending on.

A relay race with over 150 runners, where every single runner has their own personal time budget to hit, and the entire race's final time depends on every one of them staying within their own individual limit a single runner running slow doesn't just cost their own leg of the race, it risks throwing off the entire finishing time everyone else was counting on. Managing that many interconnected, independently-owned time budgets, all contributing to one single page load, is a genuinely different kind of engineering challenge than optimizing one big, unified system.

From an Internal Tool to a Public Cloud Service

Dynamo itself was never meant to be used directly by Amazon's customers it was internal infrastructure. A deep dive on ByteByteGo explains what happened next: Amazon engineers eventually concluded that combining Dynamo's core strengths scalability and predictable high performance with the easier administration, consistency options, and table-based data model of a separate internal system called SimpleDB would produce something genuinely useful well beyond Amazon's own internal walls. That combination led directly to the public launch of DynamoDB as an AWS service in 2012 a database built from the accumulated, hard-won lessons of running large-scale, non-relational storage at Amazon's own internal scale for years beforehand.

The results of that lineage are genuinely striking today. A post on the AWS Architecture Blog reports that during Prime Day 2022, DynamoDB maintained high availability while delivering single-digit-millisecond response times, peaking at 105.2 million requests per second a genuinely enormous real-world stress test of infrastructure whose design lineage traces directly back to a paper written specifically to keep a shopping cart working through a hypothetical tornado.

A family recipe, refined internally across many years of actually cooking it for a demanding home crowd, that eventually gets polished up and put on a restaurant's public menu for anyone to order the version customers order today carries every lesson learned from years of quiet, internal iteration nobody outside the kitchen ever directly witnessed.

Putting It Together

None of the individual pieces here are exotic inventions viewed entirely in isolation. Service-oriented architecture is a widely recognized pattern today, even if Amazon was genuinely early to enforce it this strictly. Key-value stores trading consistency for availability are a well-studied category of distributed system. What makes Amazon's story genuinely compelling is the sequencing: an uncomfortable, company-wide organizational mandate came first, forcing every team to think in terms of clean, potentially-external interfaces years before anyone had decided to actually sell any of it and a genuinely strict requirement, "the shopping cart must never refuse a customer," produced a database architecture disciplined enough to eventually become one of the most heavily used cloud databases in the world.

What This Means Going Forward

As Amazon keeps expanding well beyond e-commerce into cloud infrastructure, logistics, advertising, and increasingly AI-driven services, the same lesson from this article keeps resurfacing in new forms: the discipline you force onto your own internal systems today clean boundaries, honest interfaces, ruthless clarity about what a service actually promises to its callers has a way of quietly becoming the product you didn't realize you were building until years later. The lesson underneath Amazon's story isn't really about Dynamo, DynamoDB, or the API Mandate specifically. It's the same one running through this entire series: some of the most consequential architecture decisions aren't really about technology choices at all. They're about the uncomfortable organizational rules a company is willing to enforce on itself, long before the payoff of those rules is obvious to anyone following them.