Amazon 2002: The API Mandate

The context

The account is widely recounted rather than officially published, most famously in a 2011 post by a former engineer. Around 2002, Amazon's engineering organisation was directed that:

All teams would expose their data and functionality through service interfaces. Teams would communicate through those interfaces and through no other mechanism — no direct database reads, no shared memory, no back doors. And all interfaces would be designed from the ground up to be externalisable, so they could be exposed to third parties.

Why the constraints matter

The second is the one that does the work. Permitting a service interface and direct database access means the interface is optional, and under deadline pressure teams take the shortcut. Prohibiting every other path is what makes the boundary real, and it is exactly the constraint most organisations fail to enforce.

The third had a consequence that was probably not fully anticipated: designing every internal interface as though an external customer would use it produces documentation, versioning, backward compatibility and operational discipline. That is a large part of why AWS was possible as a product rather than as an internal platform with a marketing department.

The trade-off

It was, by the same accounts, painful. Service interfaces are slower to build than a shared database query. Latency increases where a join becomes a network call. Data that was trivially joinable becomes a distributed problem, and teams must reimplement aggregation across services.

The transferable lesson

Shared databases are the boundary violation that matters most, and they are almost always the reason a service-oriented estate fails to deliver independence. Two services sharing tables cannot be deployed, scaled, changed or reasoned about independently, whatever the diagram says.

The second lesson is about enforcement. The mandate worked because it was absolute and enforced, not because it was a good idea — every organisation with a service architecture believes in service interfaces, and most permit exceptions that hollow them out.

The modern equivalent is automated: schema-level access controls preventing cross-service database reads, and architecture tests failing the build on prohibited dependencies. Same principle, enforced by a mechanism rather than by a memo.