Author's Note: This post was created in collaboration with Sajjad Heydari.

Assume someone is waiting for a package to be delivered to their house. The impatient customer keeps looking out their window, waiting for the delivery truck to pull up. The patient customer keeps doing other things until they hear the doorbell ring. This everyday example can easily be transformed to the computer science domain where two types of systems exist: a polling system and an event driven system.

The polling system acts like the impatient customer. In a commerce-related scenario, it keeps polling the system for new updates such as orders and payment authorizations while the event driven system relies on asynchronous event handlers to notify it of updates in the system.

The event driven system is easier to develop and more efficient, but it requires special infrastructure to work. The good news is that some software and platforms like Fabric support event driven systems. In commerce, these systems create more streamlined operations so customers get their orders faster.

In this post, we will define what events are and how retailers can leverage them to create a system that is more efficient. But, before doing that, let’s look at an example of how an event-driven system might support a retailer and its customers.

Example of an Event Driven System

After adding multiple items to his cart, Joe goes to the checkout page on a retailer’s website. He fills in his address and payment information, then places his order. But what happens next?

With a polling system, Joe's order is stored in a database. Some time later, a script or person queries the database for any new orders and processes the payment. Another script or person in the warehouse then queries the database and starts the delivery procedure.

This way of handling payment and fulfillment is slow and prone to error. Now more than ever, handling events in real time is important in commerce given the rise in online ordering.

Polling a system periodically can create a bottleneck in operations, especially if there is an unexpected spike in order activity. Furthermore, querying a database when no new orders have been placed results in unnecessary infrastructure costs.

In an event-driven system, here is how Joe's order is processed:

1. Joe's order is stored in a database like before, but this time an event is emitted to an event router.
2. The event router looks up what that can handle this type of event and discovers that the payment processing script is responsible for it.
3. The payment processing script calls the payment processor (e.g. Stripe) with the appropriate payment data.
4. The payment processing script emits a payment authorized event. This event initiates an order confirmation email to Joe and a notification to the warehouse for fulfillment.

Parts of an Event Driven System

The Event

Event based systems in computer science go back to the 1950s where they were first designed to handle asynchronous events such as Input/Output). Edsger Wybe Dijkstra designed the first interrupt handler on the Electrologica X-1 that is still used in modern systems to this day. The modern day's events are the same concept, only they are used in different environments.

When a CPU interrupt emerges, the system changes its behavior to address the incoming interrupt. This could be a new keystroke pressed or a notification that this process is about to be terminated. The interrupt doesn't tell the process what to do, only that some event has happened. It is the process's duty to handle the interrupt and decide what to do with it.

The same thing happens with events in event driven systems. When an event is created, the event itself shouldn't decide what happens; it should only describe what has happened, be it a change in state or an update. For instance, in a modern commerce tech stack, the event router may send an abandoned cart event to an email platform like Klaviyo that decides to enroll Joe in an abandoned cart email sequence.

The Event Router

How an event is structured and emitted relies heavily on the event router. There are many different types of event routers, including AWS EventBridge, Apache Kafka, and Microsoft Event Hub.

Events are JSON documents that follow a specific scheme. The top-level fields are the same across all event types, but the detail of each event is application dependent.

For example, if Joe successfully ordered an item from a retailer, his "order created" event would look something like this...

{
  "cartId": "314919ab8aed637123f804eb",
  "orderCurrency": "USD",
  "orderTotal": 27.64,
  "orderId": "314919ab8aed637123f804eb",
  "shipTo": [
    {
      "address": {
      "name": {
        "first": "John",
        "last": "Smith"
      },
      "phone": {
        "number": "5555555555",
        "kind": "mobile"
      },
      "email": "user1@gmail.com",
      "street1": "1250 main street",
      "street2": "",
      "city": "HAVRE DE GRACE",
      "state": "MD",
      "country": "US",
      "zipCode": "21078-3213",
      "kind": "shipping"
      },
      "shipmentCarrier": "FedEx"
    }
  ],
  "items": [
    {
      "itemId": 4912,
      "price": 122.43,
      "quantity": 1,
      "total": 122.43
    },
    {
      "itemId": 8123,
      "price": 21.99,
      "quantity": 3,
      "total": 65.97
    }
  ]
}

The most straightforward way to handle events in a custom way is by using a function-as-a-service (FaaS) solution like AWS Lambda that natively supports Java, Go, Powershell, Node.js, C#, Python, and Ruby, but provides a Runtime API to allow usage of any other programming language.

Developing Lambda functions is easier and cheaper to operate since AWS only charges for the time that they are running. This is known as serverless, another technology we use at Fabric to make commerce more extensible and scalable.

Benefits of Event Driven Systems

Event driven systems are ideal for commerce since many commerce setups contain different services and microservices that benefit from being decoupled. Payments, promotions, pricing, subscriptions, search, and reviews are just a few of these services.

Decoupling allows for a faster development cycle since each service can be developed independently, cheaper runtime since each service can be scaled independently, and faster page load times. Event driven systems facilitate the decoupling of services as different services can talk to each other through the event router without directly depending on each other.

Another benefit of event driven systems are their potential to handle faulty situations. If two services rely on each other and one of them fails for any reason, the other one wouldn't be able to function properly. But through the help of event routers, if a service becomes inaccessible for any reason (such as updates or errors), the event router stores the event until it can be delivered to its intended handlers. For instance, in a scenario where the payment processing script is unavailable, the shopping cart should still be functional.

Conclusion

In this post we provided an overview of how event driven systems streamline commerce. For a more detailed view of how events and event routers allow different services to communicate better in a commerce tech stack, check out this video from AWS.