By 2001 the Obidos monolith behind amazon.com had become a deployment bottleneck, and a famous internal mandate broke it into services owned by two-pizza teams.

Amazon.com ran on Obidos: a monolith, in the strict sense the term is used here — a single application with one codebase, one database, and one deployment unit. It worked. Amazon was one of the earliest companies to formalise the microservices pattern, but it did not start there, and monoliths are often the right place to start.

The trouble is what a monolith does as the team around it grows. Every change, no matter how small, redeploys the whole application. Every service shares the same process, the same store, the same blast radius.

By 2001, the symptom had a shape. Shipping anything to amazon.com meant coordinating across hundreds of engineers. Obidos had stopped being an application and started being a queue that everybody stood in.

And the queue had a failure mode attached. A single bad commit could ground the whole site.

Line the symptoms up and they all point the same direction. The whole application redeploys for any change, so your change waits on everyone else’s. One bug can take down the whole app, so everyone else’s change is a risk to you. Scaling means scaling the entire app, even when only one feature is hot.

None of those are bugs in Obidos. They are properties of the shape Obidos was in. Because the codebase was a single deployment unit, coordination cost grew with headcount rather than with the size of the change — which is exactly why hundreds of engineers found themselves negotiating over one repository.

The culprit was never a slow query or a bad library. It was that nothing in the system forced teams apart. When any piece of code can call any other piece of code in-process, there is no seam to deploy along, no seam to fail along, and no seam to own.

The fix was an internal mandate from Jeff Bezos, and it is now famous: every team would expose its capabilities as a service over the network; every service would be built as if it would one day be exposed externally; and there would be no other form of inter-process communication.

That last clause is the one that bites. It is not advice about how to design services — it is a ban on the in-process shortcut that made the monolith a monolith. Obidos was decomposed into hundreds of services, each owned by a “two-pizza team,” small enough to be fed by two pizzas, and each team was made responsible for its service end to end: design, build, deploy, monitor, on-call. Teams owed each other service-level SLAs; if your service was slow, downstream teams could publicly hold you accountable.

The trigger here was a constraint, not a preference: deploys were slow and teams were stepping on each other. The decomposition was the answer to that, and the interesting move was not “smaller pieces” — plenty of monoliths have modules. It was removing every route between the pieces except the public one.

A service boundary is only real if the shortcut around it is unavailable; otherwise it’s a naming convention with extra steps.