How Do You Effectively Orchestrate Commerce Services and APIs?
As commerce applications evolve, they start using more services such as order services, invoice services, fulfillment services, and shipping services. These services are often decoupled—or, able to communicate with one another but not dependent on one another—which allows the commerce application to scale. It also allows developers to upgrade one service without affecting the function of other services, thereby increasing development speed and reducing errors.
These services communicate with one another via application program interfaces (APIs). But as more services are added, it becomes difficult to orchestrate APIs and commerce applications devolve to a coupled state.
Traditional service orchestration in commerce
With traditional service orchestration found in commerce applications, something called synchronous API communication is used. With synchronous API communication, services are dependent on one another which creates problems. Not only are commerce applications slower; they’re prone to error.
Consider a scenario where a rewards service is added to a commerce application. To deploy the service fast, the team responsible for the rewards service only connects the service to the order service. But if the fulfillment service errors, the rewards credited to the customer are not reversed because the rewards service is not connected to the fulfillment service. The invoice, payment, and forecasting services are updated, but the rewards service continues functioning in a silo, tightly coupled with the order service.
In this scenario, the commerce application looks like it’s decoupled but there are actually dependencies. These dependencies cause data inconsistency across services and even revenue loss (e.g. excessive customer credits).
Modern service orchestration in commerce
To avoid issues with traditional service orchestration, development teams building commerce applications orchestrate services with events. With an event driven system in place, events are observable by services but not directed by the upstream service (e.g. the order service). These events are handled by an event router, also known as an event bus.
With this type of orchestration, the event bus/router notifies the downstream services (e.g. invoice service) that an order was placed but does not command them to do anything. If the event is relevant to the service, that service will take action.
This event driven system solves for issues like the rewards service issue mentioned above. No longer is the rewards service dependent on the order service. The team responsible for the rewards service just needs to add a new rule to the event bus/router to connect it with—but not have it be dependent on—other services.
How we orchestrate commerce services
At Fabric, we use an event bus/router to orchestrate the commerce services and APIs that make up our commerce platform. Commerce services and APIs outside of our platform can also be connected to these services and APIs. The event bus/routher makes this possible and allows for a gradual evolution of a commerce application rather than a complete replatform.
To learn more about this type of modern service orchestration, you can watch the short video by AWS that this post is based on. In the video, the name of the event bus/router is EventBridge.
Tech advocate and lead editor @ fabric. Previously StackPath, Upkeep, StackShare, MaxCDN.
Related Content
