Implemented a Scalable Service Bus for ATIMO

Client

Startup "ATIMO" is a participant in the StartupDrive accelerator program by "Gazprom Neft." The "ATIMO" team has developed an application for taxi fleets and auto parks that automates the issuance of waybills. Thanks to this application, taxi fleets no longer need to employ medical professionals for pre-trip driver examinations or mechanics to inspect vehicles.

As of March 2023, the "ATIMO" application was being used by 20 taxi fleets, with a database containing over 35,000 records of drivers and vehicles.

Problem

The initial architecture posed challenges for scalability. In the initial months, "ATIMO" worked with three contractors, each of whom had their own database. The system connected directly to the required database, retrieved data about drivers and vehicles, and generated waybills. The reverse process worked in the same way: taxi fleets accessed the "ATIMO" database, downloaded waybills and logs. This approach was effective at the start, but scaling to new contractors was not straightforward. Each connection required custom configuration, and the data formats in the taxi fleet databases needed to be adapted to match the expected format.

Furthermore, direct connections consumed substantial resources. Querying one contractor could occupy 1 to 4 GB of memory on the "ATIMO" server, while only 32 GB was available. Given the existing resources, the client could add about 8-10 large taxi fleets to the system. A larger number of new contractors would result in noticeable delays and errors in data retrieval.

Additionally, direct connections did not guarantee security. If malicious actors were to compromise the infrastructure of any connected taxi fleet, they could potentially gain access to the "ATIMO" systems.

Scaling the system became slow, complex, and resource-intensive. To address this issue, "ATIMO" turned to KT.Team.

Task

The objectives were to simplify scalability, reduce server resource consumption, and enhance the client's system's security. Specifically, the goals were to establish a connection between the taxi fleet and the client's system that would allow for quick addition of new contractor databases, reduce memory usage during queries, prevent direct access to the "ATIMO" server and database by contractors, and ensure the retrieval of up-to-date data every 20 minutes or more frequently.

KT.Team focused solely on the portion of the client's business processes related to connecting with taxi fleet databases. The process of how "ATIMO" retrieves information from automated inspection points, processes it, and generates waybills was beyond the scope of the task.

Context

Before each trip, every driver in the taxi fleet needs to obtain a waybill containing information about the driver's health and the condition of the vehicle. To accomplish this, taxi fleets need to either employ an on-site doctor and mechanic or make use of services from third-party organizations.

ATIMO proposed simplifying the interaction between taxi fleets and contractors for obtaining waybills. The startup provides its clients with access to automated service points staffed by a doctor and a mechanic. The driver authenticates themselves at such a point using their phone number, after which the doctor examines them, and the mechanic checks the vehicle. All data is uploaded into the system, processed, and used to generate an electronic waybill.

In order to generate a waybill, the ATIMO application requires data about drivers and vehicles, including:

• Mobile phone number
• Driver's full name
• Date of birth
• Driver's license information
• Vehicle registration certificate
• Motor third-party liability insurance policy number

The application needs to connect to the taxi fleet's database to retrieve this data. Each taxi fleet may have multiple databases. For instance, different branches may use separate databases, or a taxi fleet may maintain distinct databases for drivers and vehicles. Each taxi fleet has its own rules for storing information, which can lead to variations in field names in tables and data formats. It's important to account for these differences and standardize all fields to ensure the system can process them.

‍

The same data is stored in different formats at different taxi fleets.

Medical and technical examination logs and completed waybills are stored on the ATIMO server. If a taxi fleet needs to access this data, they connect to the server, authenticate, and download the information.

‍

KT.Team implemented an enterprise service bus (ESB) for data exchange between taxi fleets and ATIMO.

With this solution, ATIMO now has a single point of connection, the ESB, meaning that taxi fleets can no longer directly connect to ATIMO's database to exchange data. This improved the security of interactions for all parties involved.

The ESB connects to the taxi fleet's database, retrieves driver and vehicle data, and stores it locally. From there, the data is transmitted to ATIMO. ATIMO then returns completed waybills to the ESB. The ESB retrieves these waybills and stores them in a second repository. As a result, any taxi fleet can send requests to the ESB and obtain waybills for their drivers.

The ESB formats data from the taxi fleet's database to ensure that it's delivered to ATIMO in a format suitable for processing. Each service is configured with mapping rules for data transformation.

KT.Team iterated on the solution's architecture three times to achieve the optimal result. In the first version, the bus polled all databases using a single service.

‍

The first approach efficiently saved server resources but lacked fault tolerance. Since all requests were processed sequentially, an error while connecting to the first taxi company could disrupt all subsequent ones.

In the second version of the architecture, the bus connected to each database through a separate service. This required slightly more server resources but eliminated the risk of a massive failure due to a single unavailable database or another error.

‍

Additionally, this solution involved many additional stages, such as error collection and logging, which required extra time and memory for processing. Therefore, the architecture needed to be simplified and streamlined.

The final version of the architecture is also based on separate services for each point of connection.

All services work the same way:

• They connect to the taxi company's database.
• Download the data.
• Adapt them to the format used by the client's system.
• Record new data in storage.
• Remove outdated data.

To add a new taxi company, you need to copy one of the existing services and configure it, such as replacing mapping rules. To make this task easier for the client, KT.Team used the low-code solution Mule as the basis for the bus. This tool does not require programming skills, so any ATIMO employee can work with it.

In addition, KT.Team prepared a step-by-step guide for setting up a point of connection, describing all the nuances.

‍

Results

1. The service bus allowed "ATIMO" to connect with 20 taxi companies. This includes 42 separate points of connection, as many of the clients have more than one database.
2. The bus connects to each taxi company through a separate service. Even if one of the services fails or the taxi company's database becomes unavailable, it will not affect the data of other clients.
3. Connecting to a taxi company's database takes less than 1 second for most clients.
4. The entire process, from connecting to a taxi company to loading the ready information into the "ATIMO" database, takes a maximum of two minutes. This value holds true for the slowest clients with outdated database management systems or slow connection speeds.
5. Separate services for each database and the simple scheme of their work helped save server resources. Each request now requires 300-500 MB instead of 1-4 GB. It is possible to connect to all taxi companies simultaneously.
6. Taxi companies do not connect directly to "ATIMO," so there is no risk of the client's system being compromised through a poorly secured client database.
7. The system is easily scalable. The client can copy and configure new points of connection following the instructions. A person without development experience can add a taxi company in just a couple of hours.