The other day our co-founder had a discovery call with the chief technology officer of a fast-growing business that had custom-built its own e-commerce platform with a team of in-house developers. The custom platform worked but it was getting more difficult to maintain as the business scaled.
As a subscription-based business, one of the most difficult pieces to maintain was the subscription service. With custom-built platforms these types of services are usually built within the platform’s main code base, creating an unscalable amount of dependencies and QA tickets.
To achieve scalable commerce, services like this need to be decoupled from the main platform. When services are decoupled, they are referred to as microservices.
To free up internal development resources, businesses purchase microservices that are developed, maintained, and secured by third party vendors. These microservices are connected with other microservices and backend systems via pub-sub (see second diagram below); and they are integrated into frontends and storefronts via APIs (see first diagram below).
This loose coupling of services allows businesses to select the best commerce services from a variety of vendors to create a scalable commerce platform. This type of platform is also referred to as modular commerce and headless commerce.
The technology that makes up the backend are microservices that are complemented by robust and open APIs. The APIs are what make everything fit together. They also allow internal development teams to add new services in an agile manner. In short, a scalable commerce platform is modular, yet cohesive.
Some microservices and commerce APIs in a commerce platform’s backend include:
Scalable commerce architecture is one that allows for a combination of microservices from third parties, internal development teams, and platform providers.
Below you can see how Fabric supports scalable commerce architectures that rely on Fabric’s suite of microservices as well as those from third parties (3rd Party SaaS) and internal development teams (Custom Apps).
Connections between disparate services are made possible through an “event bus.” The one used by Fabric is AWS’s EventBridge. This makes it easy to connect applications together because you can ingest, filter and deliver events without writing custom code. These events trigger actions that create custom shopping experiences.
At the time of this writing, Fabric is building a subscription service to support businesses like the one mentioned at the beginning of this article. However, we also understand that businesses that want to replatform have some existing services that work perfectly fine. In these cases, a mix-and-match approach is preferred over a rip-and-replace approach. A truly scalable commerce platform allows for the former, without exception.