Geo Caching

Fastly has been making some great progress towards their Compute@Edge offering and a recent talk by Sean Leach on The future of Fastly’s edge showcased a geo caching project I worked on several years ago.

When I started working on the HotelTonight platform my first project was revamping the API endpoints that powered the iPhone, iPad, and Android mobile devices.

When the app loaded it displayed a list of the 10 best hotel deals in your area. The Geo component of the result set was running against a MySQL database which would often see timeouts when under heavy load.

We had the Fastly team (including the infamous “Doc”) by the office for lunch to chat about their CDN offering. With our tummies full of delicious tacos we started riffing on ways to cache the inventory endpoint at the edge.

The mobile devices queried the inventory endpoint with a 6 digit lat/lon which presented some challenges for caching because the high precision of the lat/lon in the URL would result in very low cache hit rate.

GET /v1/inventory?lat=37.774929&lon=-122.419418

At the core of Fastly is Varnish, an open source web accelerator. Varnish includes support for manipulating the inbound request flow with Varnish Configuration Language (VCL).

So we posed the question: could we reduce the lat/lon precision at the edge to boost the cache hit ratio without sacraficing the quality of inventory results?

If we were to round the lat/lon to 0.01 precision it would enable us to create a bounded box of 1.11 km.

before:   lat=37.774929&lon=-122.419418
after:    lat=37.77&lon=-122.41

The bounded boxes worked like a charm. The custom VCL code created a grid of geo cached points throughout the city.

While Fastly does support instant purging we decided to do the inital deploy with 1 minute TTL. This would allow us to continue to serve great geo located results while protecting the DB from thundering heards of deal seakers.