Scale Wars #3 — Amazon: Two-Pizza Teams and the SOA Manifesto

Year: 2002 · Crisis: Jeff Bezos's infamous "API Mandate" memo

The Problem: Teams Lost in the Monolith

Before 2002, Amazon was a massive monolith. Every developer had to understand the entire codebase. New features took months. Different teams fought over the same code.

Architectural Decision: Bezos's "API Mandate" Memo

Jeff Bezos sent a memo to the entire engineering organization. This memo became one of the most famous documents in tech history:

"All teams will henceforth expose their data and functionality through service interfaces."

"There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network."

"All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions."

"Anyone who doesn't do this will be fired."

"Thank you; have a nice day!"

This memo put Amazon on the path to Service-Oriented Architecture (SOA). And that architectural decision, years later, gave birth to AWS (Amazon Web Services). Because Amazon's internal services were so well-designed, they could be sold to the outside world.

The Two-Pizza Teams Philosophy

Another one of Bezos's rules: "A team should be small enough to be fed by two pizzas."

Ideal team size: 6–10 people
Each team owns one or more microservices
The team is responsible for the entire lifecycle: Design, development, deployment, monitoring, incident response
"You build it, you run it" philosophy

Amazon's SOA Principles

SOA rules that leaked from Amazon's internal documentation:

Each team owns its own database. Shared databases are forbidden. If you need another team's data, call their API.
Every service has a network-accessible API. Direct database reads are forbidden.
Services don't know each other's internal implementation. Only the contract matters.
Each service can scale independently. If one service is under load, only that service scales.
Asynchronous communication is preferred. Synchronous HTTP calls are a last resort.

The Birth of DynamoDB: Amazon's Database Revolution

Traditional relational databases (Oracle, MySQL) couldn't keep up with Amazon's own e-commerce site. On Black Friday, hundreds of thousands of requests per second were hitting the system. Horizontal scaling was hard.

In 2012, DynamoDB was announced. It was based on Amazon's 2007 academic paper: "Dynamo: Amazon's Highly Available Key-value Store."

Key features of DynamoDB:

Key-Value Store: No SQL, no JOINs. Just key-value.
Horizontal Scalability: Add as many partitions as you need.
Consistency Models:
- Eventually Consistent: Faster, but you might not immediately see the latest write
- Strongly Consistent: Slower, but always returns the most current data
SLA: 99.999% (Five Nines) uptime

// DynamoDB with optimistic locking
const params = {
  TableName: 'Orders',
  Key: { orderId: 'ord_12345' },
  UpdateExpression: 'SET #status = :newStatus, updatedAt = :now',
  ConditionExpression: '#status = :expectedStatus',  // Optimistic locking
  ExpressionAttributeNames: {
    '#status': 'status'
  },
  ExpressionAttributeValues: {
    ':newStatus': 'SHIPPED',
    ':expectedStatus': 'PAID',
    ':now': Date.now()
  }
};

await dynamoDb.update(params).promise();

Amazon's Two-Way Door Philosophy

At Amazon, decisions fall into two categories:

One-Way Door Decisions: Irreversible, requiring careful deliberation (e.g., database schema changes, publishing a public API)
Two-Way Door Decisions: Reversible, can be made quickly and tested (e.g., adding a feature flag, UI changes)

"Most decisions are two-way doors. Make them fast and experiment. If it turns out to be wrong, walk back through the door."

This philosophy is the cultural reason behind Amazon's ability to make thousands of deployments per day.

Trade-offs

✅ Gains:

Independence: Each team moves at its own pace
Ownership: The team owns its service's fate
Scalability: The system grows with the organization

❌ Costs:

Cultural transformation: "I just write code, deployment is ops' job" mentality dies
Operational burden: Each team manages its own CI/CD, monitoring, alerting
Duplicate work: Every team can reinvent their own auth, logging, metrics infrastructure → Platform Engineering becomes necessary

🛠️ Takeaways

Conway's Law is real: your org structure determines your system architecture. If you want microservices, make the organization micro first. Design even internal services as if they were external APIs — it makes future refactors dramatically easier. "A shared database is shared pain." Each service should manage its own data. And above all: Two-pizza teams, you-build-it-you-run-it — these are cultural decisions, not technological ones. Culture comes before technology.