Deploying Our Own Geocoding ServersDason Goh
Detrack is a Software-as-a-Service (SaaS) for last mile delivery tracking, just like many other modern SaaS solutions being offered for HRM, CRM, and ERP today.
However compared to other SaaS, I’d like to think that our job is tougher.
Being a delivery tracking solution, we not only have to help our users manage their deliveries, but we also need to provide location data and logic so that we can help our users make sense of all the information we are capturing for them.
For instance, when a driver’s mobile phone sends back a pair of geographic coordinates i.e. latitude and longitude, we need to display a human readable address to the dashboard user – and not some seemingly random numbers.
Can you tell where your driver is if I tell you that your driver is currently located at 51.500729, -0.124625? Or would you prefer me to display to you that your driver is currently at “67 Bridge St, Westminster, London SW1A 2PW, UK”?
(Hint: geographical coordinates 51.500729, -0.124625 does in fact resolves to the human readable address “67 Bridge St, Westminster, London SW1A 2PW, UK”)
Now this process of converting a pair of geographical coordinates to a human readable address is what we call “reverse geocoding” in the geek world. Google Maps, the de facto mapping solution, does this very well and there are other solutions such as Mapbox, MapQuest, and OpenCage, etc. that provide similar services based on open data from OpenStreetMap.
As you may have guessed, Detrack relies heavily on mapping functions to provide location data and logic to our users, and reverse geocoding is one of our most frequently used function. What you may not know is that unlike most tracking solutions, we do not use Google Maps. Instead, we rely on mostly non-Google mapping solutions to achieve an extra oomph of cost effectiveness, agility, and licensing freedom that we translate into unique business value for our users.
Until recently, Detrack has been using several mapping solution providers to power the different parts of our app. However a recent outage from one of our key providers nudged us to relook at our stack and ask ourselves: “Can we improve the stability of our infrastructure without sacrificing our mojo?”
Surprisingly simple – we just need to be a mapping solution provider ourselves.
And that we did.
Detrack has since deployed a total of six of our own failover dedicated geocoding servers (each with 6 Core Xeon Processor, 12GB RAM, 192GB SSD) to power both our reverse and forward geocoding needs.
And this is only the beginning.
Many SaaS rely heavily on other SaaS to work, and this is something that we want different in Detrack. We will be embarking on a journey to reduce our reliance on external providers, especially for critical functions such as mapping.
Our next target? Hmm… how about our very own dedicated route planning servers?
That’ll be totally awesome.