One question we frequently get asked is “How real time is your tracking experience?” When we respond saying it’s near real time (~4 second latency) the follow up is “You must be collecting GPS locations very frequently, what’s the impact on battery life?” The fact is we only consume ~5% of battery per hour of tracking. So your fully charged phone can last full day of tracking without breaking a sweat. This blog is a deep dive on how we achieved close to real time tracking with minimal battery usage – two things that are perpetually in tension with each other in the smartphone tracking world. Continue reading
“You can’t sacrifice partition tolerance” – is one of the more influential articles that I have read on distributed systems design. It talks about applying the CAP theorem: in any distributed system design, choosing between consistency, availability and partition tolerance is a trilemma – you can only choose two of the three.
Theoretical computer science aside, the point it makes is that any practical distributed system needs to have partition tolerance built in. Remote nodes will die, networks will be flaky, and message packets will get lost – and that is how the world is.
Building great products is a team sport. Developers who built location features in their products using HyperTrack required multiple team members to access the HyperTrack dashboard to access account keys, edit account details and track live trips during pilot. Once they completed the development, users wanted their operations and customer service teams to be able to use the dashboard to track their drivers, monitor their performance and see real time alerts. So far, they did not have a way to give access of dashboard to all their team members, and they ended up sharing the login credentials with everyone who they wanted to provide access. Yikes! Continue reading
In the field of location tracking there needs to be lot of back-and-forth communication between devices and the backend. Device transmits location stream and health information (battery level, network strength, etc.). Backend processes this information, applies business logic on top and sends configuration commands back to devices in order to orchestrate tracking. These configuration commands determine when to start/stop tracking, frequency at which to collect GPS data (time and distance), frequency at which to transmit GPS data and so on.
In a world with patchy mobile networks making all this communication robust is quite a task. It is important to choose the right network protocol and design the communication semantics to get maximum benefit of the protocol’s capabilities. We recently switched a large part of our device-backend communication from HTTP to MQTT. This blog is about how we achieved it and our learning from it so far.