Amazon: from monolith to SOA

01 · CONTEXT

One site, one application, shared databases

This case is read from a summary published on High Scalability, built from an interview with Amazon's CTO. It is a third-party summary, not the primary text of the interview.

The architecture change the text describes is the move from a two-tier monolith to a decentralized, distributed service platform that serves several applications. At first there was one application talking to a back end.

1. At first there was one application talking to a back end; the diagram shows the browser, the front-end application, and the databases.

2. For years the scaling effort was making the back-end databases grow to hold more items, customers, and orders and to serve several international sites.

3. The databases became a shared resource, which made it hard to scale the business as a whole.

4. Front end and back end evolved under constraints because they were shared by many teams and processes.

5. In 2001 it became clear that the front-end application no longer scaled.

The text points to two pain points: the databases as a shared resource, and evolution held back by a front end and back end shared by many teams and processes.

02 · THE SHIFT TO SERVICES

Data behind service interfaces

The answer was to split the databases into small parts and create, around each part, a service interface that became the only access path to the data.

In today's terms, it is the idea behind microservices with domain boundaries that are well defined, although the text talks about service-oriented architecture.

1. The databases were split into small parts, and each part got a service interface that is the only access path to the data.

2. The architecture grew to hundreds of services and application servers that aggregate their information; the diagram shows only a few.

3. The application that renders the Amazon.com pages is one of these application servers, and the web services interface is another.

4. To build a page, between 100 and 150 services are accessed; only three appear here.

5. Clients do not access the database directly: this way the service can scale and become more reliable without involving whoever consumes it.

6. Web services are offered externally in SOAP and REST, with 30% using SOAP and 70% using REST; the diagram shows the web services interface.

A design detail: a single mechanism for accessing services makes it easier to aggregate, route requests in a decentralized way, and trace across the distributed system.

03 · TEAMS AND OPERATIONS

A service is also a team unit

Services are the independent units that deliver functionality and also the way the company organizes its teams. A team is limited to 8-10 people, the so-called two-pizza teams, and is given the authority to solve the problem as a service in whatever way it sees fit.

Another lesson from the text is that whoever builds also operates (you build it, you run it), which brings daily contact with the customer. Internally, SLAs are used to manage services.

An interview question that follows from this: should a service's boundary coincide with the boundary of what a small team can own end to end, data included?

04 · STATE AND CAP

Availability in the cart, consistency in the order

The summary treats state management as the central problem in large-scale systems, but notes that few operations are stateful; the checkout steps are.

By CAP theorem, a shared-data system has at most two of three properties. To scale you must partition, which leaves choosing between strong consistency or high availability for a specific system.

1. In the cart, the request to add an item is always accepted, because that generates revenue; errors are hidden from the customer and resolved later.

2. When the order is submitted, consistency is favored, because credit card, shipping and handling, and reporting access the data at the same time.

3. The choice of approach depends on the needs of each service.

05 · LESSONS AND CAUTIONS

What to take away and what not to generalize

Among the lessons of the text: keep things as simple as possible, with no hidden requirements and dependencies, and note that many third-party technologies are hard to scale to Amazon's size.