Strava Engineering: infrastructure

Serving Maps for the World's Athletes

The Strava mobile clients and website render millions of map images every day to provide geographic context to activities, routes, segments, and more. [We use and love Mapbox](http://labs.strava.com/blog/tailoring-maps-strava-athletes/) for our interactive maps on the web, but because of our high volume of requests, we came to a point where it was more economical to build our own static map service.

View More.

Mesos at Strava

Over the past few years at Strava, server side development has rapidly transitioned from our monolithic Ruby on Rails app (The Monorail) to a service oriented architecture with services written in Scala, Ruby, and golang. This post describes how we use Mesos, Marathon, and Docker to deploy nearly 100 different services in an efficient and reliable way.

View More.

Futures/Promises in the Land of Golang

These days a common bottleneck in execution time is the network. It simply takes a long time to make the round trip (several milliseconds, versus a 100th of that to process the result). So, if you're doing multiple network requests, it makes sense to do them in parallel to reduce the overall latency. Futures/promises are a technique to accomplish this.

View More.

Finagle Compatible Service Discovery in Golang

What we all know and love about Strava is running on a mostly Rails code base. However, as we've grown we've slowly been moving to a more service-oriented architecture. Almost all new features are being implemented as their own service and a few existing features, like the feed, have also been migrated. Most of these services are written in Scala and use Finagle/Thrift for their RPC communication layer. A growing number of services are starting to use Go and it's becoming necessary to cross communicate. A big hurdle in this process has been service discovery, i.e. how clients determine the IP and port for a service that can exist on multiple hosts.

View More.