Amazon's architecture has undergone tremendous changes, from a two-tier architecture at the beginning to a distributed, decentralized service platform that provides many different applications.

Initially, there was only one application to interact with the backend, which was done in C++.

The architecture will evolve over time. For many years, Amazon has focused its main efforts on increasing capacity on the backend database, trying to accommodate more product data, more customer data, more order data, and support multiple international sites. By 2001, it was obvious that the front-end application could no longer make any efforts to increase capacity. The database was divided into many small parts, and a service interface was created around each part, and the interface was the only way to access the data.

The database gradually evolved into a shared resource, which made it difficult to increase capacity on the basis of the entire business. The evolution of front-end and back-end processing was greatly limited because they were shared by too many different teams and processes.

Their architecture is loosely coupled and built around services. The isolation provided by the service-oriented architecture allows them to develop many software components quickly and independently.

Gradually, Amazon has hundreds of services and several application servers that aggregate information from the services. The application that generates the http://Amazon.com site page is located on such an application server. The application that provides web service interfaces, customer service applications, and seller interfaces is similar.

Many third-party technologies are difficult to apply to the scale of Amazon's website, especially communication infrastructure technologies. They work well within a certain scope, but if the scope is expanded, they are not applicable. Therefore, Amazon has to develop the corresponding basic technologies by itself.

Don't "hang" on one technology. Amazon uses jboss/java in some places, but only uses serves, and does not fully use the technologies involved in j2ee.

Programs developed in C++ are used to process requests. Programs developed by Per/Mason are used to generate content in the page.

Amazon does not like to use middleware technology because it looks more like a framework than a tool. If you use a certain type of middleware, you are stuck with the software model that middleware uses. You can only use their software. If you want to use different software, it is almost impossible. You are trapped! What often happens is that message middleware, data persistence layer middleware, Ajax, etc. They are all too complicated. If the middleware can be provided in the form of smaller components, more like a tool rather than a framework, it may be more attractive to us.

SOAP-related web solutions seem to want to solve all distributed system problems again.

Amazon provides two types of web services, SOAP and REST. About 30% of users use SOAP as a web service. They seem to be Java and .NET users, and use WSD to generate remote object interfaces. About 70% of users use REST. They seem to be PHP and PER users.

Whether SOAP or REST is used, developers can get access to Amazon's object interface. Developers want to get the work done without worrying about what is transmitted on the network wire.

Amazon wants to build an open community around their services. They chose Web Services because of its simplicity. In fact, it is a service-oriented architecture. Simply put, you can only access the required data through interfaces. These interfaces are described by WSD, but they use their own encapsulation and transmission mechanisms.