In the early 2000s, Amazon’s e-commerce website was built using a traditional, coupled platform. Most companies start out with this monolithic type of platform but many outgrow it over time. This is because the business becomes more complex and the codebase expands.
With these platforms, all the commerce services are tightly connected. Developers at Amazon had to work through dependencies between services when it was time to make updates or scale. Because of this, changes to a single service often resulted in changing the system as a whole.
In 2001, Amazon wanted to expand its product catalog and knew its e-commerce system had to be upgraded. They needed an architecture to scale individual services. They also needed a streamlined development release pipeline.
In this article, we’ll examine the architecture and development software Amazon uses for its in-house e-commerce platform today.
Amazon decided to create a decoupled architecture where functions could only communicate through APIs. To do this, they started restructuring their applications into smaller pieces. Each function was broken out into an individual service. Developers took the functional code and added a web interface. They then began using the service to run that commerce function. Everything from the search engine to the shopping cart had its own service.
Amazon changed its organizational structure to better suit the new e-commerce architecture. Before, Amazon’s development teams worked together on applications. This meant that any releases had to be organized across teams.
They decided to move to small autonomous teams of developers. Each independent service was assigned to one of these teams. Developers could invest all their focus on a single service. This helped Amazon identify and resolve development issues more efficiently.
Amazon’s distributed architecture became an early example of what is now known as microservices. Applications are broken down to a single function, communicating through APIs.
With microservices, Amazon had unlimited flexibility. They could edit or add commerce functionality to their e-commerce system as they saw fit.
Note: Amazon began making in-house solutions like AWS available to customers sometime after this which played a big role in helping other companies create service-oriented architectures.
Decoupling its services helped Amazon create one of the first automated release pipelines. The deployment system was the early version of Apollo which Amazon eventually made available to customers. The system helped Amazon automate manual software delivery processes, enabling developers to use continuous integration and continuous deployment (CI/CD).
CI/CD gave Amazon the ability to rapidly test code while reducing human error. Code is compiled in a central repository, then put through automated tests. This helps Amazon detect issues before they become a bigger problem.
The ability to make changes quickly has helped drastically reduce the number of outages for Amazon. Since enhancing its release pipeline, Amazon averages mere seconds between new code deployments.
In summary, Amazon uses its own custom-built e-commerce platform. The scope and complexity of their business render traditional e-commerce platforms ineffective. The only way they can continue to create best-in-class customer experiences is through headless commerce.
Fabric understands this, which is why we created headless commerce services and APIs. Businesses with e-commerce operations can now build e-commerce infrastructure like Amazon—all without Amazon-level resources. You can think of Fabric as the AWS of commerce.