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.
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.
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.