How Delivery Hero perfects restaurant operations using gamification with Amazon DynamoDB

This post is co-written with André Paschoal and Miloš Marinković from Delivery Hero.

Delivery Hero, based in Berlin, Germany, is the world’s leading local delivery platform, operating its service across Asia, Europe, Latin America, the Middle East and North Africa. Delivery Hero works with more than 1.5 million restaurant partners and local vendors in over 70 countries to transport hundreds of millions of food orders, groceries, and more to customers daily through online ordering applications.

In this post, we provide an overview of Delivery Hero’s goals and how we used Amazon DynamoDB to build a scalable and cost-efficient solution, leveraging gamification to improve restaurant operations.

The appetizer

At Delivery Hero, we saw an opportunity to streamline the user experience for restaurant partners and local vendors:

• Online time for partner restaurants: Some restaurant partners experienced difficulties in adhering to their specified online availability hours. We aim to ensure that our restaurant partners can reliably be listed on our platforms for the duration they have specified.
• Minimize order failures: We aim to minimize order failures caused by item out-of-stock situations, improving customer satisfaction and reducing operational inefficiencies.
• Facilitate timely order preparation and optimized logistics: We aim to ensure that orders are ready for pick-up promptly and delivered to customers in the best possible condition.

The solution – Hero Points & Leaderboards

We built the Hero Points system to gamify restaurant partners’ day-to-day operations. When partners complete specific tasks in the Restaurant app, they earn Hero Points. Our most commonly updated tasks are: reporting food preparation times, ensuring accurate order details, coordinating with the rider network, updating menus, and providing timely check-ins.

It’s a win-win situation! Riders get their orders faster, restaurant partners receive recognition and rewards for their outstanding efforts, and the customers get an excellent experience.

We also launched weekly and monthly leaderboards to encourage participation from restaurant partners. Using our leaderboards, partners can quickly see how they stack up against their peers, and adjust their operations accordingly to earn more Hero Points.

Tech

Delivery Hero used Amazon Web Services (AWS) to build this solution. AWS offers over 15 purpose-built database engines to support diverse data models—including relational, key-value, document, in-memory, graph, time series, and wide column databases.

Selecting the right database solution was a critical decision. Thorough evaluations (including multiple proof-of-concepts) and an in-depth review of the use case were conducted over the course of several months. The culmination of our research resulted in choosing DynamoDB, primarily because of the pay-per-request pricing model which is a cost-efficient solution for our use-cases, prior experience, and confidence that DynamoDB can scale to support our application requirements.

The ability to scale to the peak capacity needed by 1.5 million restaurant partners, single-digit millisecond performance at any scale, and the resiliency covered by the 99.99 percent Standard SLA offered by DynamoDB was instrumental to the launch of the Hero Points system.

We built the Hero Points service to consume tasks completed by restaurants from external services using Amazon Simple Notification Service (Amazon SNS) and Amazon Simple Queue Service (Amazon SQS), award points for these tasks in the service, and store the results in DynamoDB. We also built a cronjob to aggregate the results for the leaderboard and store them in DynamoDB. We made the leaderboard available to our restaurant partners exposing the service running on Amazon Elastic Kubernetes Service (Amazon EKS) via an API Gateway.

The main dish

The core of the solution is tracking points earned by restaurant partners. The tasks performed by those partners that earn points come through sources like APIs and messaging or events. When reporting an accomplished task, the user must provide:

• Restaurant partner ID
• Accomplished task
• Date the task was accomplished

Each task awards a specific number of points which are stored in a DynamoDB Points item, but also adds up to a Monthly Balance item. To achieve that, we use DynamoDB transactional writes.

The items stored in DynamoDB consist of a partition key on restaurant partner ID combined with a sort key specific to the entity. For example, the following image shows the monthly balance or a composite value that uniquely identifies an item that represents a task that generated Hero Points.

The balance can be accessed in multiple places in the Restaurant app and is by far the most read item. Reading in DynamoDB is fairly cost efficient, which eliminated the need to implement any sort of caching for users to view balance updates in real-time.

Computing the leaderboard

Players are grouped, usually by location or delivery area, and each group has its own leaderboard. These leaderboards are computed and updated once at the end of the day, after all the earning-points tasks and events have been processed. Computing the leaderboards once per day has an impact on the promptness of data compared to leaderboards that get updated in real time. This design decision to update the leaderboard on an interval was appropriate given the business requirements and allowed us to optimize the data model for reads.

The algorithm looks like the following:

• For each group
  • Fetch the points balance for each player. This can be implemented with a straightforward DynamoDB query specifying a key condition expression on the partition key: PK = POINTS#<REST_PART_ID>
    And an additional key condition expression on the sort key: begins_with(SK,POINTS_ITEM#<DATE>#)
  • Rank the group
  • Write the leaderboard into DynamoDB

The leaderboard user interface

Before looking into the details of the leaderboard item, it’s important to understand the UI. There we want to show:

• The Podium, which includes ranks 1, 2, and 3
• The current player and their immediate neighbors

With that, the number of players in the leaderboard can vary between 3 and 6. The following tables are examples:

Current player ranked second

Current player ranked tenth

The leaderboard item

The leaderboard item should look like the following to enable the UI.

The partition key is a composite key based on the following parts:

• The model was created using DynamoDB single-table design and contains data from different entities, so a prefix of LB is used to make the leaderboards easily identifiable.
• A date range for the evaluation
• The group assigned to this player

The player ID is used as the sort key, making sure that the DynamoDB table has a unique item for each player participating in this leaderboard.

From the UI, we can infer that the leaderboard items will be read in two different ways:

• By player ID
• By rank

To achieve that, we used DynamoDB Indexes, in this case a global secondary index (GSI), where the rank becomes the sort key.

A typical leaderboard has over 100 players, so most players won’t be part of the top four players on that board. We use the following steps to retrieve the leaderboard data (although the data for the top four items require less data to be retrieved):

1. Find the current player: Get item from table, by player ID
2. Find neighbors: Get item from the GSI, by rank two times (n-1 and n+1)
3. Find podium players: Query the GSI for rank between 1 and 3

Most of the time, reading the leaderboard means six read operations.

Given the tiny size of the leaderboard item and the overall amount of data stored, we later introduced a read optimization, by storing the neighbors along with the items, switching from six reads to two. The neighbor data contains a collection of key-value pairs such as the restaurant name and player identifier, their points, and their rank.

Right-sizing read operations

By reducing the number of required read operations from six to two, the overall latency was reduced. At the same time, the effectiveness of both reads and writes improved by optimizing the available size per request unit. These changes didn’t impact the write capacity consumption because the extended set of attributes for each leaderboard item still fitted well within 1 KB and therefore continued to use one write capacity unit (WCU) per leaderboard update.

DynamoDB read requests can be either strongly consistent, eventually consistent, or transactional.

• A strongly consistent read request of an item up to 4 KB requires one read request unit.
• An eventually consistent read request of an item up to 4 KB requires one-half read request unit.
• A transactional read request of an item up to 4 KB requires two read request units.

One write request unit represents one write for an item up to 1 KB in size. Transactional write requests require 2 write request units to perform one write for items up to 1 KB.

To support our access pattern, eventual consistent reads are sufficient. We preferred the 50 percent cost reduction of eventual consistent reads over strongly consistent reads, because the latter would have a limited positive impact on the customer experience.

The initial six reads each were smaller than 4 KB, resulting in a total read consumption of 6 x 0.5 read capacity units (RCU) = 3 RCU consumption for each time we retrieved the leaderboard position for one player. With the optimized read pattern, we now consume 2 x 0.5 RCU = 1 RCU because both reads continue to fit within the 4 KB limit. This resulted in another 66 percent reduction in the cost of retrieving this data.

Conclusion

Since implementing our gamification strategy with Hero Points, we’ve witnessed remarkable improvements in our operations to meet our goals:

• Order Failure Prevention: We prevented €2.6M in order failures because of forgotten check-ins by vendors, as vendors collecting points are more compliant with check-in times.
• Delivery Optimization: The usage of the “Food is Ready” feature increased by around 9 percent, reducing friction on delivery and status updates. Gamification encouraged vendors to proactively mark their food as ready, thereby ensuring a reduction in order delay rate.
• Feature adoption: Specific features adoption improved by up to 50 percent, as it encouraged certain micro-interactions among our users.

Delivery Hero’s journey to operational excellence and enhanced partner engagement through gamification has been a game-changer in the online food delivery industry. From Delivery Hero – Miloš Marinković, André Paschoal, and Sneha Saha were involved in this project. In their own words:

“As we continue to evolve and innovate, we remain committed to delivering exceptional experiences for our customers, riders, and partners. This project was an amazing ride, from learning from AWS Specialists about which services could help us and how to use them to benchmark costs and performance, and then incrementally designing and improving our solution to gamify our customers’ experience” – André Paschoal.

If you want to learn more about the use cases from Delivery Hero with AWS, check out Delivery Hero on AWS.

About the authors 

Miloš Marinković is a Senior Engineering Manager at Delivery Hero, based in Berlin. His work focuses on advancing restaurant software using a mix of tech innovation and organizational strategy. His expertise lies in software engineering, mobile and cloud computing, and machine learning integrations, complemented by a strong commitment to open-source and a passion for continuous learning and community engagement in tech.

André Paschoal is an Engineering Manager at Delivery Hero based in Berlin, Germany. André joined Delivery Hero in February 2020 as a JVM Backend Engineer having Kotlin as primary language. He is passionate about collaborative work and XP practices.

Joseph Idicula Watasseril (he/him) is a Senior Solutions Architect at AWS, based in Berlin. With over 12 years of experience in tech consulting and software development, Joseph works with Delivery Hero to harness the power of cloud solutions for business challenges. He is passionate about advancing innovation in areas such as scalability, agility, and digital transformation.

Arjan Schaaf (he/him) is a Senior DynamoDB Specialist Solutions Architect at AWS, based in Amsterdam, The Netherlands. Arjan (he/him) joined AWS in August 2020 with over 20 years of experience in software development. In his current role, he works with customers on a daily basis to educate them about DynamoDB and help them design and optimize their DynamoDB workloads.