Case Study: Amazon's Two-Pizza Teams and Service Ownership

Amazon's contribution to microservices was not a technology but an insight about organization, arrived at years before the word "microservices" existed: the way you structure your teams determines the architecture you end up with, so you had better structure the teams on purpose.

Amazon turned that insight into a small set of rules that hang together as a system. Teams talk to each other only through service interfaces. Teams are small enough to be fed by two pizzas. A team that builds a service also runs it. Every service has exactly one owning team. None of these rules is complicated, and each sounds almost trivial in isolation. Their power comes from how they reinforce each other, and from the cultural scaffolding underneath them that companies copying the rules tend to forget to build.

For an interview, Amazon is the reference for when the conversation turns to team-to-service mapping, ownership, and why a clean service diagram fails if no team can own the boxes. This chapter covers the rules, why they work together, and what gets lost when they are copied without the culture.