MatHem.se Scales Grocery Delivery App with Amazon EventBridge

Guest post by Pranjali Deshpande, Senior Product Manager, and Tom McCarthy, Startup Solutions Architect, AWS

In the current pandemic, online grocery delivery services have been elevated to essential services, almost overnight. Not only did grocery delivery companies have to scale up their physical infrastructure to meet new demand, as well as health and hygiene standards, their technology stack also had to be flexible to scale-up seamlessly. MatHem.se is Sweden’s leading independent pure-play online grocery retailer.

In March 2020, MatHem.se saw a huge surge in customer demand almost overnight. The number of concurrent users trying to place a grocery order increased by 800% day-over-day. Since the MatHem.se team had previously taken on a project to rewrite their entire application stack to be entirely serverless and event-driven, they were able to handle this increase in load without needing to make any significant changes. However, delivery times that used to be sufficient for a day ran out in a few minutes. To avoid disappointment for customers reaching the checkout page only to find the times were gone, they needed to act quickly and add new functionality. They decided to give customers the option to reserve a delivery time slot before adding groceries to the cart.

As MatHem.se has grown, both their applications and the development teams that create them have become more distributed. To release new features, the development teams often needed to spend time co-ordinating with other teams to make changes which spanned multiple services. To reduce this coupling, and allow development teams more freedom to operate and innovate independently, MatHem.se incorporated Amazon EventBridge into their architecture.

Lars Jacobsson, Principal Technical Architect at MatHem.se, walked us through some of the benefits they’ve seen after adopting Amazon EventBridge. “With Amazon EventBridge, we leverage the versatility offered by content filtering and input transformation to reduce unnecessary invocations and complexity of our AWS Lambda functions. Before EventBridge, unnecessary invocations led to more cost and more clutter in our logs,” said Jacobsson.

MatHem.se adopted an Amazon DynamoDB to EventBridge fanout pattern using AWS Lambda in between. Whenever a DynamoDB item changes, DynamoDB Streams delivers events to EventBridge using a Lambda function. This provides MatHem.se a simple way to react to and process those events, by triggering consumers such as Lambda and AWS Step Functions.

How MatHem.se uses Amazon EventBridge in their event-driven services architecture

The Flow

[1] When a customer selects the delivery time slot in the UI, the delivery time is added to the cart object in the cart-service, triggering an event to EventBridge.

[2] The delivery-time service that processes event emitted by step [1] to create a new entry in the Reservation DynamoDB table tracks all the delivery time reservations with reservation status =  Active. This table entry emits another event to EventBridge.

[3] An EventBridge rule triggers an AWS Step Functions state machine for events with reservation status = active.

[4] Since a customer can only hold a delivery time slot for 40 minutes, this state machine has a wait state set to 40 minutes. After the wait state, the state machine runs a Lambda function to set the reservation status to expired if the reservation status is active (meaning the order hasn’t been completed). This update in status emits another event to EventBridge.

[5] The cart-service listens to events from step [4] to check for events with a reservation status of “expired”. The cart-service then removes the delivery time slot reservation from the shopping cart.

[6] If the customer completes the order in 40 minutes, the reservation status is updated to “confirmed” as part of the checkout process.

The team had used AWS SNS/AWS SQS for their event processing needs before turning to EventBridge. While the SNS to SQS publish/subscribe pattern has its benefits, in MatHem.se’s case, it led to a tight coupling between services and teams. A service subscribing to events from the publisher needed to know exactly which SNS topic the event was published to, and relied on documentation to understand the schema. Subscribers had to co-ordinate with publishers to ensure that the right attributes were added to each message so that they could be filtered appropriately.

With EventBridge, all events are published to a single event bus making it easy for subscribers to find them. In addition, EventBridge rules enable subscribers to filter on any field in the event, so they can filter events on a granular level. With the EventBridge Schema Registry, the team can publish their event schema to a central location, making it easy for developers on other teams to quickly find the structure of their events, reducing the coupling between teams and enabling them to be more independent. In MatHem.se’s case, most events triggered by the producers are based on mutations to DynamoDB data. Consumers browse the schema registry and build patterns based on it. To ease the process of writing patterns and reduce human errors, the MatHem.se team developed an open-source tool evb-cli to enable developers to quicky build patterns and browse destinations for which schemas are being used.

By moving to a serverless architecture, MatHem.se was able to speed up new feature releases by 5-10 times. The adoption of Amazon EventBridge accelerated this even further, by reducing the amount of time development teams spend co-ordinating with each other to develop and launch new features. MatHem.se demonstrated their speed and agility by developing and launching an MVP of the delivery time reservation functionality in only 3 days.

Wondering how to build event-driven applications using Amazon EventBridge? See our Learning Path Series for Eventbridge.