Beat Tesla Lifecycle: A deep look through engineers’ eyes
Breaking down Beat Tesla’s basic operational steps.
Introduction
Beat Tesla service left a mark on the city of Mexico as a high-tech, premium, sustainable and safe solution that revolutionizes the way you move in the city. One of the most important factors for the success of this project is arguably our partner drivers who interact with Beat passengers, helping them move throughout the city. To facilitate their day-to-day life when driving Beat Tesla, our engineering team developed a backend microservices ecosystem that aimed to tackle the array of challenges that were required to be solved towards making every Beat Tesla ride a success.
The Life Cycle
The lifecycle of Beat Tesla begins with the preparation of the driver shifts. When a shift is due to start, the driver is scheduled to use a Tesla vehicle at a specific parking lot of CDMX. After logging in to the Beat Driver app using their credentials, a shift officially begins. At this point, we need to direct our partner drivers to specific hotspots in the city of Mexico, places where their chances to serve Beat Tesla rides are more likely. At the end of the shift, the partner drivers are again directed back to the Tesla vehicles parking lot, for our team to receive the vehicle, and prepare it for the next driver shift.
In this article, we will mainly focus on the creation and management of the driver shifts and the monitoring of their performance. Then, we will go over the main elements and architecture of the respective services and the factors that drove their development.
Shift Management
A system of particular importance for Beat Tesla is the Shift Management Service. This is a tool that allows Beat Tesla operation teams to generate and view the schedule of our partner drivers.
Every week, a schedule with the partner drivers’ shifts is generated by an intelligent algorithm that considers:
- The number of available vehicles.
- The number of available partner drivers.
- The start/end timestamp of each shift.
- The time required to charge the vehicle.
- Some additional driver constraints (e.g. driver unavailability).
Then, our parking lot agents can have a daily and weekly overview of the shifts through an internal dashboard. In addition, they can apply last-minute changes to the schedule and view which shifts started on time and which ones were delayed.
For a Beat Tesla driver to start a shift, two requirements should be met:
- The driver must log in from an authorized iOS device mounted on the Tesla vehicle. Each Tesla vehicle is paired with an iOS device based on a unique device ID.
- Partner drivers must be included in the shift schedule either as scheduled or as backup partner drivers.
Fulfilling the aforementioned requirements officially marks the start of a driver’s shift. The Shift Management Service is the source of truth regarding shifts for other systems such as the Driver Performance Service.
Driver Performance
To ensure Beat delivers a seamless experience to its users riding with Beat Tesla, we needed to produce a definite set of quality measures for the new service. One of the most interesting factors that directly affect the quality of the final product is the driver’s performance.
Measuring a driver’s performance can seem like a simple task at first glance. In reality, it is influenced by a multitude of factors during the timespan of a shift. From customer-facing driver attributes like their behavior and degree of professionalism to the effectiveness of the Beat Tesla fleet as a whole, partner drivers have to operate within specific standards set by Beat.
To that end, they are evaluated based on a set of Key Performance Indicators (KPIs) available on the “My Performance” section of the Beat Driver app. This aims to help partner drivers stay on track with their performance at any point during their shift and when necessary take corrective actions. Some critical parameters that we take into consideration include:
- Driver availability during the scheduled shift hours.
- Cancellation rate of passenger requests.
- Passenger ratings.
These performance metrics are presented to partner drivers in two formats based on time; “Current shift”, and “Last 6 shifts”. Through a simple UI, partner drivers can easily switch between the two and find a detailed breakdown of their performance for each case.
In the “Current shift” view, partner drivers are informed about their ongoing performance, based on a view with live metrics, while they are driving. Based on the color that’s used for rendering a metric, they can check how their performance stands against certain threshold values for a particular dimension.
As you can see in Figure 3, in the “Last 6 shifts” view, partner drivers can either navigate past shifts to individually inspect the respective performances they achieved on a certain day, similarly to the “Current shift”, or look at an overview generated from the latest shifts. This overview provides intuitive graphs and average scores across each metric that enable partner drivers to track their past progress in terms of their performance over a specified period and identify areas for improvement. A simple interface is also used here with a familiar color scheme in line with the thresholds that were applied when evaluating their performance.
Returning to Parking Lot
When a shift is coming to an end, the partner driver should gradually start moving back towards the parking lot. This is crucial for two reasons. First and foremost, as discussed in a previous section, partner drivers work based on predetermined schedules. Thus, we need to ensure that they are not staying in the streets for longer than their shift’s bounds. Secondly, in the case that a vehicle is planned to be utilized in back-to-back shifts, given that it is adequately charged and ready, any significant delays on one shift will have a knock-on effect on the following driver shifts, causing a chain of frustration.
To tackle these issues, we take into consideration the distance of the partner driver from the parking lot when the shift is about to end and issue directions for them to return through the Beat Driver app. This is achieved by calculating the estimated time of arrival (ETA) to the parking lot using the Google API and measuring the remaining time from the end of the shift. At this point, we also take into account other affecting variables, for instance, the time it takes for a driver to deliver the vehicle.
When the partner driver reaches the parking lot and the vehicle is delivered successfully, we consider the shift as completed. After preparing the vehicle for the upcoming driver shifts, it is added to the pool of the available Tesla vehicles.
Architectural Overview
Beat Tesla’s components design and implementation extended Beat’s already existing microservices architecture in a natural manner, utilizing many of its benefits.
A shift entails information about the driver, the schedule, and the specific Tesla vehicle from our fleet that is going to be used for performing rides. The Shift Management Service, which is responsible for the creation and validation of driver shifts, persists the shift data in Amazon Aurora MySQL. Data for shifts and partner drivers can fit perfectly in a relational database, as their schema is not expected to change often and data integrity is key, thus we opted for the usage of MySQL for this service.
The shift data also has to be available in the Driver Performance Service which is responsible for calculating metrics for every given driver shift. As Figure 4 illustrates, the Shift Management Service and the Driver Performance Service are deployed as separate microservices. This by itself imposes a challenge regarding their communication. To keep the services decoupled from each other and allow for a continuous flow of data to the Driver Performance Service, the team adopted a stream-based asynchronous approach for capturing events about new shifts starting when the partner drivers enter their vehicle in real-time. For that purpose, we extensively used Apache Kafka.
Both services were developed in the Go programming language using Beat’s OSS Microservice Framework Patron. Patron provides a convenient Apache Kafka async component that we used to consume events from various Apache Kafka topics as they are produced from an array of services of Beat’s backend architecture.
The Shift Management service is producing events to a Kafka topic, specific to driver shifts, for each partner driver that enters a Beat Tesla vehicle and logs in to the Beat Driver app. Then, the Driver Performance Service consumes these events and creates a new document in a MongoDB Atlas collection for each shift. Subsequent business events that are produced during the shift of a driver (e.g. when a ride ends, a driver is rated, etc) are associated with the corresponding driver shift. These events are produced from microservices that curate different domains of the Beat business. Upon request from the clients, they contribute to the calculation of various metrics that are useful for the partner driver.
Instead of using a more traditional database solution (e.g. MySQL), we opted for MongoDB since the business events that are produced from the various Beat’s Backend microservices have different schemas, and thus, we wanted to have the ability to incorporate and handle all these dynamic data in a more natural manner. All the complexity regarding the handling and processing of these events is managed programmatically, which considerably reduces redundant data in each Shift Performance MongoDB document. We maintain a timeline of events that occurred during a shift as nested documents inside the respective shift performance document. Ultimately these data, through various MongoDB pipelines, are used for the calculation of the performance data that our partner drivers can view through their Beat Mobile clients.
The partner shift data, provided from the Shift Management Service and the shift performance data as they are curated from the Driver Performance Service, are available through the Beat Driver app to our partner drivers. At Beat, the various microservices communicate with our clients through a service that acts as a gateway — the Beat API. The shift and performance data are also available to our Beat Agents through an internal dashboard, the Shift Management & Performance Dashboard. Through this tool, they can view and edit the driver shifts, view the event timelines of each driver shift, and comment on specific events when needed. This considerably improves the quality of service delivered, while at the same time, it greatly helps the operational aspect of managing the Tesla fleet. As it is depicted in the aforementioned illustration, this particular dashboard communicates through HTTP both with the Shift Management as well as the Driver Performance microservices. This increases the usability of the tool since our agents have a single monitoring solution for their day-to-day Beat Tesla management activities.
Conclusion
At Beat, we strive to look at things in depth when possible and we are not satisfied until we find the best applicable solutions in terms of usability, scalability, maintainability, and performance. We iterate on our solution over and over again, constantly trying to provide our customers with the best experience possible. When we have interesting cases that others might find useful, we try to share them through blog posts similar to this.
The development and launch of this new service came at a very critical time for the world and all our communities, when people were invited to discover new ways to move and connect. During these extraordinary times, and while working on a full remote mode, Team Beat achieved to hit one more milestone for the company and the industry reaffirming that flexibility, collaboration, and innovation are the key ingredients to a brighter future. Our deep collaboration and the team’s excellence foundations established throughout the years, allowed us to continue bringing new mobility solutions and tangible value to our customers and partners.
If you found this article interesting and looking for your new challenge, check out our open roles. Join us on the ride!
About the authors
Georgios Chronis is an Engineering Manager at Beat. He is particularly interested in designing large-scale web applications and services.
Georgios Kechagias is a Software Engineer at Beat, member of the Backend Chapter. He loves tackling complex problems through simple, scalable, and performant solutions. Interested in DDD, microservices, and event-driven architectures.
Konstantinos Moraitis is a Software Engineer at Beat. He is genuinely interested in software design, clean code, and building scalable microservices in Go.
