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.
A better custom delivery which led to a 3% drop in the overall bad order rate.
Ongoing monitoring of the platform using Logstash and Kibana allowing their team to react quickly and easily.
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.
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.
"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."
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.
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.
"There were other tools at the time probably slightly more mature in terms of geospatial, but Elasticsearch is fundamentally a search tool,[...]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.
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.
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.
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.
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.
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.