30 August 2017 User Stories

Get a Break and Search Fast with Snaptrip and Elasticsearch

By Maciej Rakowicz

Snaptrip.com specialises in last-minute staycations, providing savings of up to 60% on cottages, lodges, and apartments in the UK.

Making Search Real Fast

One of our priorities is to make search fast, accurate, and detailed for our customers. Our site lists many thousands of properties, but users don't want to scroll through page after page choosing the right property for them. Understandably, given what we do, we want them to be able to find properties that are available, and match their requirements, quickly and easily. To do this, we use Elasticsearch as we had great experiences with it in the past and it allows us to have a cluster in the cloud that we can provision, upgrade and manage with little dev-ops effort.

We've looked at other cloud solutions mainly to test their real life support, however, Elasticsearch & Elastic Cloud seemed to be the best fit for us from the start. Our key search functions include complex feature filtering, map zoom pan (bounding box search), and the combination of property specs with availability information from multiple sources to bring in the most accurate results. In particular, the Elasticsearch sorting flexibility is amazing as we can play with it without having to run a full re-indexing which helps a lot (re-indexing is heavy in our case, there's a lot of bits and pieces that build a single document).

Elasticsearch is basically used as an aggregations/cache layer that powers all website searches. It combines data from actual systems of records and makes it available via a common, query-able interface. We keep documents in sync by running background jobs (batch processes) throughout a day. In addition, whenever we notice a price or availability change an event is fired and the aggregation & reindexing task kicks in to process it asynchronously. We have them carefully scheduled to meet business requirements but also to throttle load on any other components of our infrastructure and external infrastructures we integrate with (basically external APIs).

In the grand scheme of things, we store a very small volume of data, but a lot of nested documents and the overall size of data indexable documents is not trivial. It's challenging for memory especially during heavy batch job.

image3.png

Improving Customer Experience

Earlier this year, we were also able to quickly implement a new and novel site feature – 'travel time'. It uses a complex polygon search to restrict results to properties within a certain driving distance of the user's location.

image.pngSearch for driving distance

image (1).pngPolygon showing locations within 1.5 hours drive of Legoland - only properties within this area will be returned for this particular search

The polygon query uses a geo_polygon filter with a pre-calculated polygon points.

... more filters ...
"geo_polygon": {
    "location": {
        "points": [a set of polygon points, precalculated]
    }
 }
... more filters ...

where "location" is mapped as: "type": "geo_point".

We use the Elasticsearch Ruby client (version 1.0.6). The query expressed in Ruby looks as shown above, a Ruby hash. However, polygon generation is the complex bit. We are running a relatively complex recursive isochrone algorithm that uses our self-hosted graph/routing service. It eventually spits out a GeoJSON that can be passed as is to the Elasticsearch filter. Our lessons learned mainly focus on the isochrone algorithm - balancing between accuracy and real time performance. Elasticsearch performs well for the polygons of up to 100 points that we supply.

We're also working on improving the results users see based on various user and inventory metadata, and Elasticsearch makes this very complex sort ordering possible.

Technical & Business Benefits

Thinking back, we made a really quick start with Elasticsearch with only one senior developer engineer with minor previous Elasticsearch production experience who set it all up. Today, Elasticsearch greatly helps us reduce the level of work required to aggregate data for results, and build complex search features for our small, lean development team. It uses an expressive query language which helps to troubleshoot and understand complex queries, as they are easy to comprehend. It also helps us keep our average response time very low at 100ms. Since we have used Elasticsearch from the very beginning, we don't have a before and after comparison, however, we're very happy with the results we've gotten so far.

Elasticsearch has significantly improved our ability to provide our customers with accurate pricing and availability details, in a space where inaccurate information is far too common.

Besides Elastic Cloud, we also use X-Pack security to make sure that our data is always protected to the highest standards.

Looking Ahead

We've been looking into Kibana. As a business, we store a significant amount of data which has huge value, but getting insights from data can be very time consuming and often requires specialist knowledge. Our early trials of Kibana are very promising - we can quickly explore our large quantity of data, create visualisations to help comprehension, and give tools to team members who are not specialised, as the interface is great to allow exploration without needing to write code.


Maciej Rakowicz is Snaptrip's Lead Engineer, which means his job involves taking care of everything that a customer doesn't usually see. He works from his home in the Czech Republic, but his favourite place in the UK has to be London due to the eclectic architecture and how much there is to do! It's basically the world in a nutshell and, like several other wonderful UK destinations, absolutely worth a short break.