Just Eat No Longer Bites Off More Than It Can Chew​

Thanks to the geospatial features in Elasticsearch Just Eat's restaurant partners have fewer bad orders on their plates. The bad order rate dropped by 3% overall, and by up to 20% for individual restaurants.

Find your flavour

Just Eat's 17.6 million customers placed 136.4 million takeaway orders in 2016, alone. The company's 68,500 restaurant partners have to deliver all that piping hot food as quickly and efficiently as possible across geographically-sprawling delivery areas. Bad order rate, the percentage of orders requiring manual intervention, is one of the company's key metrics. Late or lukewarm food often leads to a bad order.

17.6 million
customers in 2016
136.4 million
takeaways in 2016
200-300 searches
per second at peak times

Just Eat's Journey with Elastic

The Who

Matthew Jones is a Principal Engineer and the Search Component Lead at Just Eat UK, making him responsible for the technical architecture, security, stability, and scalability of the search components.

"Search is part of the core order flow for Just Eat. It is the main way that consumers find the restaurant they want to order from. Our main challenges in the search domain are stability, response time, and search result accuracy which led us to Elasticsearch."

Matthew Jones, Principal Engineer, Just Eat

The What

Just Eat UK's original restaurant search was based on postcode districts, which can be many miles across. Restaurants would sometimes reject orders which came from too far away, even if they were technically within their delivery district, pushing up the bad order rate.

"We found a lot of restaurants only wanted to deliver to parts of a district, not the whole thing," said Jones.

In fact, custom delivery areas was the second most requested search feature (The most requested feature was the ability to edit menu items) from Just Eat's restaurant partners. Jones and his team decided to step up to the plate.

image2.png

Just Eat's homepage

The Why

First, the team needed a search tool with geospatial features. "There were other tools at the time probably slightly more mature in terms of geospatial, but Elasticsearch is fundamentally a search tool," said Jones. "It had a more well-rounded set of features that we could utilize long term, so it was more of a long-term decision."

X-pack is used to monitor the Elasticsearch cluster and provides security features. All technical departments at Just Eat use a separate Logstash and Kibana cluster to monitor the entire platform. From Kibana they can view IIS logs for any of their APIs or web applications and view application logs for any component in their platform whether it's an API, a web application or even a Windows service. This allows their teams to quickly and easily do root cause analysis of any issues in near real-time.

Just Eat signed up for a platinum subscription in order to gain better insight into how the cluster was performing under load and to get support in areas like best practices and query performance tuning. For example, the Just Eat team got help on performance issues like deciding how many primary shards to allocate to get the best performance, while still maintaining high reliability.

The How

Just Eat's restaurant partners typically only wanted to deliver within, say, a two mile radius, but customers could search for restaurants using a postcode district which might extend well beyond that two miles. A user searching for restaurants within the London postcode SE1 1AA, for example, would see a list of restaurants delivering to the SE1 district. That district was used as a key in Amazon DynamoDB, a NoSQL database, to retrieve a list of restaurants which delivered to that district.

image1.png
Restaurant Search Before Custom Delivery Areas


The team considered using more granular postcode sectors like SE1 1xx (where the xx part is ignored) to calculate restaurant delivery areas but polygons, which can capture any shape that can be drawn on a map, are more accurate than districts and easier to manage than sectors. So polygons as supported by Elasticsearch were used to implement the new custom delivery areas.

image3.png
District Polygon


A polygon is a bounded area represented by the set of latitude and longitude points. All the existing districts first had to be transformed into polygons and saved to an S3 table (as the new shapes were too large for DynamoDB) from which they can be retrieved using the district postcode. The retrieved district shape is then used for indexing restaurants in Elasticsearch.

Restaurants can now define their location, which is transformed into latitude and longitude, and a delivery distance limit (e.g. two miles) from that location. A circular polygon defines the delivery radius of a particular restaurant. The open source C# library Clipper is used to calculate a custom polygon based on the intersection between the delivery radius and district polygons. This custom polygon defines the exact delivery area of a restaurant within a district. As long as a user's address falls within this clipped polygon shape, then the restaurant will deliver to them.

image4.png
Custom Delivery Polygon


Initially a simple distance limit was used to calculate a restaurant's delivery area, but Elasticsearch can also be used to define more complex delivery rules. For example, a restaurant in London might have a delivery radius of three miles, but not want its drivers to cross the river Thames. "We have added additional support for more complex, custom polygons using KMLs (Keyhole Markup Language files) with or without exclusion zones," said Jones. Restaurant delivery areas were also previously only updated periodically, increasing the risk of stale data. Now they are updated in near real time whenever the restaurant makes a change.

The Results

Custom delivery areas have proved to be highly popular with restaurants, an important consideration when restaurant satisfaction is one of Just Eat's most important metrics. But the biggest result since introducing custom delivery areas has been a 3% drop in the bad order rate in the UK. Bad orders require manual intervention which leads to higher costs and disgruntled customers. Some individual restaurants saw drops of up to 20% in their bad order rate.

"Our current roadmap is to migrate more of the International Just Eat countries to using Elasticsearch's geospatial queries in the core search flow."

Matthew Jones, Principal Engineer, Just Eat

Custom delivery areas mean that more hungry Just Eat customers can now find their flavour.

Just Eat's clusters

Number of Clusters 2
Number of Nodes 3x master, 12x data (UK), 3x master, 6x data (International)
Hosting Environment AWS EC2
Total Data Size 30GB (UK), 10GB (International)
Number of Indices 3x per country
Query Rate 200 per sec (UK), 10 per sec (International)
Replicas 3x
Time-based Indices 0
Number of Clusters 2

Location:
London, UK

Industries:
Food & Beverage/ Hospitality

Use Case:
Application Search

Elastic Products Used:
Elasticsearch
Kibana
Logstash
X-Pack security and monitoring features
Support

Elastic Subscription:
Platinum