Implemented a scalable service bus for ATIMO

Client

The startup ATIMO is a participant in the StartupDrive accelerator run by Gazprom Neft. The ATIMO team developed an app for taxi fleets and vehicle fleets that automates the issuance of trip sheets. Thanks to it, taxi fleets do not need to employ medical staff for pre-trip driver checks or mechanics to inspect vehicles.

As of March 2023, 20 taxi fleets were already using the ATIMO app, and the database stored more than 35,000 records about drivers and vehicles.

Problem: the initial architecture was difficult to scale

In its first months, the ATIMO startup worked with three counterparties, each with one database. The system connected directly to the required DB, downloaded driver and vehicle data, and generated trip sheets. The reverse flow worked on the same principle: the taxi fleet accessed ATIMO's DB and downloaded trip sheets and logs.

At the start, this solution worked well, but scaling to new counterparties was not so straightforward. For each connection point, a direct connection had to be set up, then the data format in the taxi fleet databases had to be identified and the system had to be taught to normalize it into the required form.

Direct connections also required significant resources. Polling one point used 1 to 4 GB of memory on the ATIMO server, and only 32 GB were available in total. With the existing resources, the client could add 8-10 more large taxi fleets to the system. A larger number of new counterparties would have caused noticeable delays and errors when retrieving data.

Finally, a direct connection did not guarantee security. If attackers hacked the infrastructure of any connected taxi fleet, they could use it to access ATIMO's systems.

Scaling the system became slow, complex, and resource-intensive. \\To solve this problem, ATIMO turned to KT.Team.

Goal: simplify scaling, save server resources, and secure the client's system

It is necessary to establish a taxi fleet connection to the client's system in which

KT.Team worked only on the part of the client's business processes related to connecting to taxi fleet databases. How ATIMO receives information from automated inspection points, processes it, and generates trip sheets was outside the scope of the task.

• a new counterparty database can be added quickly;
• polling one taxi fleet will require less memory;
• the partner will not have direct access to the ATIMO server and database;
• up-to-date data can be retrieved every 20 minutes or more often.

Context

Before a trip, every taxi fleet driver must receive a trip sheet with data on the driver's health and the vehicle's condition. To do this, the taxi fleet must either employ a doctor and mechanic or use third-party services.

"ATIMO" proposed that taxi fleets simplify interactions with contractors to obtain trip sheets. The startup gives its clients access to automated checkpoints staffed by a doctor and a mechanic. The driver signs in at such a point using a phone number, then the doctor examines the driver and the mechanic inspects the vehicle. All data is uploaded to the system, processed, and used to generate an electronic trip sheet.

To generate a trip sheet, the ATIMO app needs data about drivers and vehicles:

The application must connect to the taxi fleet database (DB) to retrieve them.

A single taxi fleet may have several databases. For example, different branches may use different databases, or the fleet may maintain separate databases for drivers and vehicles. Each taxi fleet has its own data storage rules: field names in tables and data formats may differ. This has to be taken into account and all fields normalized into a single format so the system can process them.

The same data is stored in different formats across different taxi fleets

Logs of medical and technical inspections, along with completed trip sheets, are stored on the ATIMO server. If a taxi fleet needs this data, it connects to the server, authenticates, and downloads it.

Service interaction diagram before the project

• mobile phone number;
• driver full name;
• date of birth;
• driver's license data;
• vehicle registration certificate;
• OSAGO insurance policy number.

KT.Team implemented a service bus for data transfer between taxi fleets and ATIMO in both directions

KT.Team designed a new data transfer scheme so that the ATIMO system would have a single connection point: the service bus (ESB). In other words, taxi fleets can no longer connect directly to the ATIMO database to send or retrieve data. Interaction security has improved for all participants in the scheme.

The bus connects to the taxi fleet database, downloads driver and vehicle data, and loads it into its own storage. From there, the data is sent to ATIMO.

Then ATIMO returns the completed trip sheets to the bus. The ESB downloads them and loads them into the second storage. After that, any taxi fleet can send a request to the bus and receive trip sheets for its drivers.

The ESB formats data from taxi fleet databases so it can be passed to ATIMO in a ready-to-process form. Mapping rules are configured inside each service.

KT.Team changed the solution architecture three times to achieve the best result. In the first version, the bus queried all databases through a single service.

This approach saved server resources, but it was not fault tolerant. Because all requests were processed one after another, an error when connecting to the first taxi fleet could interrupt 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 it prevented a widespread failure caused by one unavailable DB or another error.

In addition, this solution had many extra steps, such as collecting and logging all errors. They required extra processing time and memory, so the architecture had to be simplified and streamlined.

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

All services work the same way:

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

KT.Team also prepared a step-by-step guide for configuring the connection point, covering all the details.

• connect to the taxi fleet DB;
• download data;
• convert them into the format used by the client's system;
• write new data to the storage;
• remove outdated data.

Results

• The service bus allowed ATIMO to connect 20 taxi fleets. That is 42 separate connection points, since many counterparties have more than one database.
• The bus connects to each taxi fleet through a separate service. Even if one of the services fails or a taxi fleet database becomes unavailable, this will not affect the data of other partners.
• Connecting to the taxi fleet DB takes less than 1 second for most counterparties.
• The entire process, from connecting to the taxi fleet to loading the finished information into ATIMO's DB, takes at most two minutes. This is true even for the slowest counterparties with outdated DB management systems or low connection speeds.
• Separate services for each DB and a simple operating scheme helped save server resources. Each request now requires 300-500 MB instead of 1-4 GB. It is possible to connect to all taxi fleets at the same time.
• Taxi fleets do not connect directly to ATIMO, so there is no risk that the client's system will be hacked through a poorly protected partner database.
• The system scales easily. The client copies and configures new connection points on its own using the instructions. A person without development experience can add a taxi fleet in a couple of hours.