The API Mandate (Bezos's Service-Oriented Architecture Directive)
Ban all communication except through hardened, externalizable service interfaces.
- Difficulty
- Expert
- Time to result
- ~months to results
- Steps
- 7
- Confidence
- 90%
In the early 2000s Amazon's monolithic codebase had ground development to a halt: any team touching the code risked breaking everything else. Instead of adding more coordination, meetings, or a program-management layer (the Microsoft approach), Jeff Bezos issued a company-wide mandate banning direct communication between teams entirely. Every team had to expose its data and functionality through a documented service interface, communicate only through those interfaces, and design every interface as though it might one day be exposed to outside developers. This forced organizational decentralization and eliminated brittle, undocumented dependencies between teams. The mandate is now legendary in tech culture (thanks to Steve Yegge's leaked internal rant) and is widely credited as the structural precondition that made Amazon Web Services possible, since externalizable internal services could later become externally sellable products.
Origin
Issued by Jeff Bezos around 2002, influenced by exposure to Tim O'Reilly's Web 2.0/API philosophy, and enforced across all of Amazon; later publicized without authorization via Steve Yegge's 2011 Google Plus rant.
Core principles
- 01No inter-team communication except through documented service interfaces
- 02Every interface must be designed as if it will one day be exposed externally
- 03Technology choice per service is irrelevant as long as the interface contract holds
- 04Enforcement must be absolute, not optional
- 05Decentralizing communication is a structural fix, not a cultural aspiration
How to run it
- 1
Expose Everything Through Service Interfaces
Require every team to expose its data and functionality only through a defined service interface, not through direct database access or shared code.
Pro tip Treat this as non-negotiable infrastructure policy, not a suggestion.
- 2
Mandate Interface-Only Communication
All communication between teams must happen through these interfaces — no exceptions for 'quick' internal chats about shared data.
Watch out Verbal tribal knowledge ('that field changed purpose') undermines the entire system if allowed to persist.
- 3
Eliminate All Other Forms of Inter-Process Communication
Ban direct linking, direct reads of another team's data store, shared memory models, and any backdoors.
Watch out Backdoors that seem harmless in the short term recreate the original coupling problem.
- 4
Stay Technology-Agnostic
Let teams choose whatever technology they want to implement their service (HTTP, custom protocols, etc.) as long as the interface contract is honored.
Pro tip This preserves team autonomy while keeping the org decoupled.
- 5
Design Every Interface to Be Externalizable From Day One
Every team must plan and build its interface as though it could someday be exposed to developers outside the company, with no exceptions.
Pro tip This single requirement is what later allowed Amazon to spin internal services into AWS products.
- 6
Enforce With Real Consequences
Make compliance mandatory with clear consequences for teams that don't adopt the model.
Watch out Without teeth, teams will quietly revert to easier, tightly-coupled shortcuts.
- 7
Redirect Freed Time to Customer-Facing Work
Once teams no longer need constant cross-team negotiation, redirect that reclaimed time and attention toward building new features and improving the customer experience.
In the wild
Because every Amazon team was already required to build interfaces that could theoretically be exposed externally, the internal service layer that resulted from this mandate became the technical and cultural foundation from which AWS's earliest infrastructure services were eventually spun out and sold to developers outside the company.
→ The mandate's externalizable-by-design requirement became a direct precondition for launching AWS as a business.
Years later, former Amazon engineer Steve Yegge, then at Google, wrote a long internal reflection praising Amazon's API mandate as the one thing Amazon did better than Google. He meant to post it internally but accidentally published it publicly on Google Plus.
→ The post went viral and became one of the most cited documents in tech culture about organizational architecture.
Common mistakes
Treating Interfaces as Optional
Allowing teams to keep informal backdoors or shared database access defeats the entire purpose and recreates the original coupling problem.
Not Designing for External Use From the Start
Retrofitting an internal-only interface to be externally consumable later is far more costly than building it externalizable from day one.
Expecting Overnight Results
This was a multi-year organizational transformation at Amazon, not something that happened the moment the mandate was announced.
Is it for you?
Best for
Fast-growing engineering organizations whose monolithic codebase or tight coupling between teams is slowing shipping velocity.
Not ideal for
Very small teams or early-stage startups where the overhead of enforced interface contracts outweighs the coordination problem it solves.
From the transcript
“all teams will henceforth expose their data and functionality through service interfaces”
“anyone who doesn't do this will be fired”
From the episode
Amazon Web Services