Build Event-Driven Architecture with SP-API

The event-driven architecture pattern is an asynchronous architecture design model, which uses events to connect decoupled, independent components of a system. These components are typically microservices that run specific tasks. Instead of a monolithic application that contains all the logic, an event-driven architecture utilizes small components that generate and react to events. These events represent state changes or other types of updates.

The key elements of event-driven architecture are producers and consumers. A producer generates an event that is processed by one or more consumers in order to execute different tasks. Normally, an application consists of multiple producers and consumers. Together, these tasks accomplish a business use case.

Event-driven architectures can improve the performance of your applications by decoupling components and reducing the development lifecycle. You can use the Notifications API to implement this design model.

Benefits of event-driven architecture

Building an event-driven architecture benefits the performance, cost, reliability, scalability, and development lifecycle of an application. Examples of these benefits include:

• Event-driven applications perform better when they react to events in real-time. This is in comparison to schemas that pull data on a scheduled basis, which introduces delays.

• Reacting to events reduces the amount of unnecessary work, which helps cut costs by saving resources and usage.

• The event-driven architecture call pattern reduces the load on third-party services. Reduced loads remove the rate limit bottleneck and reduce throttling errors.

• Decoupled components can scale and fail independently. Decoupled components can adapt to demand based on individual needs, which can reduce the impact of failures.

• The development lifecycle shortens when the architecture is simpler, which makes it easier to adapt to new use cases.

Notifications and event-driven architecture

Selling Partner API (SP-API) provides the Notifications API, which you can use to build an event-driven architecture. With the Notifications API, you can subscribe to different event types and receive notifications about relevant changes to your Amazon businesses.

The use cases that are covered by the various notification types include: listing status changes, order updates, fee promotion activations, report processing completion, and product definition changes.

SP-API offers two workflows to receive notifications. One workflow uses Amazon Simple Queue Service (Amazon SQS) and the other uses Amazon EventBridge as routers for events. Depending on the notification type you want to subscribe to, you'll need to implement one of these workflows.

Amazon SQS

Amazon SQS is a fully managed message queuing service that enables the receipt of messages from different sources and their corresponding processing. The use of Amazon SQS provides a scalable, highly available, and secure solution for receiving and processing events that are relevant to the customer’s business. Amazon SQS offers multiple alternatives for processing incoming messages to provide flexibility for your application needs. This includes integration with AWS Lambda functions and using the Amazon SQS API.

A typical architecture for the Amazon SQS SP-API notifications workflow consists of a message queue and a consumer for those events. The message queue is hosted in an Amazon Web Services (AWS) account and receives notifications for events the selling partner is subscribed to. Message processing happens asynchronously and is based on the business use cases that are supported by the application.

The steps for configuring this workflow, as explained in Tutorial: Set up notifications (Amazon Simple Queue Service workflow) are:

1. Create an Amazon SQS queue in your AWS account.
2. Grant SP-API permissions to write to the queue.
3. Create an Amazon SQS destination in SP-API.
4. Subscribe a selling partner to a notification type.

To simplify building this workflow, Amazon provides a Quick Start that creates a working architecture in your AWS account with just a few clicks, and focuses on the report processing use case. To create the required infrastructure, expose API endpoints for notification management, and extend it to any other use case supported by the Notifications API, follow the steps in Selling Partner Reports API Reports Notifications in the AWS Quick Start Deployment Guide.

Amazon EventBridge

Amazon EventBridge is a serverless event bus that enables the reception of events from a variety of AWS services and client applications, as well as their corresponding distribution to different targets for processing. EventBridge is a managed, fault-tolerant service that scales based on incoming traffic. You can use EventBridge to define custom rules to filter and transform events before sending them to selected targets, which simplifies the integration between software components. EventBridge supports more than 40 Software-as-a-Service event sources for ingesting data and multiple destinations, including AWS Lambda, API Gateway, and custom HTTP endpoints.

A typical architecture for the SP-API EventBridge notifications workflow consists of an event bus that is hosted in the AWS account that receives:

• Notifications for events the selling partner is subscribed to
• One or more custom rules, and their corresponding targets

Message processing happens asynchronously and is based on the business use cases that the application supports.

The steps for configuring this workflow, as explained in Tutorial: Set up notifications (Amazon EventBridge workflow) are:

1. Create an EventBridge destination in SP-API.
2. Associate the event source with an event bus.
3. Create a rule and associate it with the event bus.
4. Subscribe a selling partner to a notification type.