How food delivery tech helps Tebita Ambulance save lives in Ethiopia.
As Deliver Addis has grown, we’ve built and scaled up our in-house technology to keep deliveries running smoothly. Much of that tech is focused on our operations helping dispatch, track, and monitor every order in real-time by constantly pulling in data from our drivers on the road and our online platform to help us make intelligent dispatching decisions quickly.
The need to make data-driven logistical decisions on the fly goes far beyond just food delivery however.
We teamed up with Tebita Ambulance, one of the first private ambulance companies in Ethiopia, to design and build a similar system to help them manage their emergency calls more efficiently and allow them to identify patterns that will help them better position and prepare their team for the day’s work ahead.
“Every minute Tebita saves when responding to a call may help save another life”
Our main objectives were:
- Make incoming emergency call processing more efficient while ensuring the system is as resilient as possible due to the critical nature of Tebita’s calls.
- Provide a way for management to analyze ambulance dispatch data to continue to make effective decisions.
Here’s how we built it.
Heads up: The following gets a bit more technical so if you enjoy that sort of thing, you’ll like the next part!
If there was any stage of this project that I could emphasize the most, this would be it. In most environments you could spin up a server in some random location and call it a day but designing solutions like this for environments like Ethiopia adds a bit more complexity. Among some of the factors working against us are:
- Unreliable internet: This shouldn’t be a surprise to anyone that has used the internet in Ethiopia but, if my life ever depended on the internet working reliably, I’d be in a lot of trouble. Given the urgency of Tebita’s work, we knew that any solution we built would need to work offline and be physically hosted at Tebita’s headquarters rather than completely relying on a server in the cloud.
- Unreliable power: Now that we knew we had to host the solution at Tebita HQ, we had to ensure that any server hosted there would have constant access to power. Despite there being a generator, there is always a period of time between when the main power cuts out and when the generator starts providing power that would be important for the server to withstand.
Adding to those challenges is the fact that this system will be used for one of Tebita’s most critical workflows and it will need to withstand any issues that the above infrastructural challenges may cause. Given the importance of the data it’ll be handling, we’ll also need a method for making regular backups both on-site and off-site (but more on that later).
It was evident early on that, due to the unreliability of the internet and power (despite having a generator), we would need to host the system on-site with the following:
- A large battery backup that could run all of the networking equipment and our server for an extended period of time just in case. Dispatchers already have laptops and UPSs that they can swap in and out so we were less concerned about that.
- A server that wouldn’t require a great deal of power which the battery backup could sustain for more than 10 hours.
The battery backup was simple enough to find since extended power outages are not uncommon here. We decided on a large deep-cycle solar battery but now we had to find a server that could run the application we would build but wouldn’t drain the battery backup excessively.
Our server of choice: Raspberry Pi 3 B+
The Raspberry Pi is a nifty bit of hardware. It’s an entire computer on a circuit board just a bit larger than a credit card and it’s powerful enough to run the application we built but not much more.
It’s also quite efficient with power (idling at ~400–450 mA) and it comes in at a cost of under $100 with accessories.
The main challenge with a low-powered server is that it likely won’t be able to handle both the application we would build as well as run the business intelligence tool that we’ll be using to help management analyze their data better. It also doesn’t fulfill our need to maintain regular off-site backups so we’re going to need a little help from an unlikely place…
Enter the cloud.
But wait, we said we can’t rely on the internet right? As it turns out, only one of our main objectives is truly critical (processing emergency calls). Our other objective (helping management better understand their data) is one that doesn’t necessarily need to be done in real-time.
The queries that the business intelligence tool would be running are also fairly database-intensive and could impact performance for dispatchers managing their calls so it’s best to offload that from our tiny server at Tebita and put it in the cloud.
We don’t need a massive server in the cloud so we can continue to keep costs low and we’ll set up an encrypted VPN between the Raspberry Pi and our cloud server so that we can replicate the database across both servers to keep all the data in sync for the analytics. We’ll also set up a cron job on our cloud server to automatically take rolling snapshots of the database multiple times per day to add just a little more resilience.
Time to build
Now that we’ve got our architecture down, its time to start coding! After interviewing and observing Tebita’s dispatchers and managers, we put our requirements list and process maps together and combined them with some of the concepts we’ve used for our own dispatching system. We opted to use a tech stack a bit different from our own given some of the requirements we discovered with Tebita and ended up with the following stack:
- Django (Python-based application development framework)
- Bootstrap (UI framework)
- MariaDB (relational database)
- Gunicorn (Python application server)
- Nginx (reverse proxy for Gunicorn)
Fun fact: Our main development machine blew a capacitor on the motherboard while development was underway. Let that be a reminder to always backup! 😊
We’re almost done! Now that we’ve addressed the architectural challenges and built the application, all that’s left is to configure the BI tool and set up the Pi in Tebita’s HQ.
Business Intelligence tool
We’ll be using an open-source business intelligence tool (Metabase) to help Tebita query & visualize their data off of the cloud server we set up.
Metabase is a perfect fit for our needs thanks to its user-friendly design and the ease at which management will be able to create useful dashboards and metrics that help them visualize their operations better.
This dispatch data is key to helping Tebita make data-driven decisions and continuously improve service quality so it’s important we make it as easy as possible to get the answers they need when they need it.
On-site installation and the little details
Since the battery backup is a little further away from the network rack, we’ll need to purchase power extensions that will ensure a snug fit on both ends so that an errant jostle won’t cause any equipment to get unplugged.
Since all the software configuration was done in the architecture phase, all that’s left is to plug the Raspberry Pi in, set a reserved IP for it on the router so everyone knows how to reach it on the network, and it’s installed!
- Dispatchers can handle critical calls even when the internet stops and all dispatch records will be synced to the cloud server in real-time or when the internet permits.
- Management can run queries and build up-to-date dashboards with dispatch data without impacting the ability for dispatchers to process calls.
This was both a rewarding and fun project for us to work on and it’s great to see these same tools and concepts we’ve used to deliver food help improve the quality of life for others that need urgent attention.
Have a project in mind for us? Let us know at email@example.com