Architecture Decoupled eCommerce Checkout Journey

I have recently been (re)familiarising myself with some of decoupling mechanisms presents within the AWS eco system. Upon looking at the EventBridge component, I saw multiple use cases for the advanced filtering logic. So I put together a potential architecture diagram to explore the use cases of these related components in an eCommerce context. eCommerce presents an interesting use case because it is the intersection of many different components, it also relies on multiple systems having a near-real time update of associated activities.

Lets dig into it.

So at the beginning we have a client interface which we are assuming is a happy path so they have been able to purchases successfully, and our application needs to notify the downstream components of this new order_state. In order to do so, our client will first pass this to the API Gateway.

API Gateway - in this diagram, the API gateway is receiving the order on a relevant endpoint and routing the request to the correct downstream. In a production environment, you may want to add some authentication layer on top of this, for example you could add API credentials to be passed in the headers of the request. This will help protect you against some malicious actors.

Once the routed from the API gateway, it we need a way of passing the message to multiple components at once. However there could be different messages for different components, so to preserve the resource on the components we will need to filter on the upstream components. So we will need to pass this to an event bus component.

Event bus - In this diagram, the event bus will receive the message from the API Gateway. By using the filtering logic in the Event Bus we can ensure that the various messages are passed to their relevant components. For example we may only want our new_order_created messages to be passed to our Shipping Gateway and Inventory Gateway. Therefore we do not need the extra fields in our Payment Gateway or CRM. So we can filter those out using the Event Bus.

Once the Event bus has filtered the message it will be passed onto its relevant Business Component e.g. Shipping Gateway, CRM, Inventory Gateway. These components could be third party software that is used for additional functionality. So we can assume these application will pass this message data into their associated data stores. For some components once the details are store in the database it will be handled separately to our application.

However, in some instances you may have CRM database which contains information about each new order and the item purchased. In these cases you may set up a notification service to notify your application of a new record in your DB table to configure an email to be sent out with the new data entered into the database. The benefit of using a CRM is that the CRM DB already has all of the details required for an order_success email to be sent. So rather than adding another destination to the event bus we can use a notification service to trigger the email service when the order is added in the CRM DB.

In conclusion, you can build a eCommerce journey that fits the needs of your application with the components in the diagram. However, it is important to fit any solution with the constraints of your application/resources. For example if your application is a subscription software service you may not need Inventory Gateway and Shipping Gateway. So it is important to tailor this to your particular use case.