Client
The startup ATIMO is a member of Gazprom Neft's StartupDrive accelerator. The ATIMO team has developed an application for taxi fleets and fleets that automates the receipt of waybills. Thanks to him, taxi companies do not need to employ medical personnel for pre-trip examinations of drivers and mechanics to check cars.
As of March 2023, 20 taxi companies were already using the ATIMO app, and the database contained more than 35,000 records about drivers and cars.
Problem: It was difficult to scale with the original architecture
In the first months, the startup ATIMO worked with three counterparties, each of whom had one database. The system connected directly to the required database, downloaded data on drivers and cars, and generated waybills. The reverse transfer worked on the same principle: the taxi fleet got access to the ATIMO database and downloaded waybills and magazines.
At the start, this solution worked well, but scaling to new contractors was not so obvious. For each connection point, you need to set up a direct connection, then determine the format of the data in the taxi fleet databases and “teach” the system to bring them to the desired form.
In addition, a direct connection requires a lot of resources. The survey of one point took from 1 to 4 GB of memory on the ATIMO server, and a total of 32 GB was available. With existing resources, the client could add 8—10 more large taxi companies to the system. More new contractors would cause noticeable delays and errors in obtaining data.
Finally, a direct connection did not guarantee safety. If attackers broke into the infrastructure of any connected taxi fleet, they could gain access to ATIMO systems through it.
Scaling up the system has become slow, complex and resource-intensive. ****To solve this problem, ATIMO contacted KT.team.
Objective: to simplify scaling, save server resources and secure the client's system
It is necessary to connect the taxi fleet to the customer's system in such a way that
- you can quickly add a new partner database;
- a survey of one taxi company will require less memory;
- the counterparty will not have direct access to the ATIMO server and database;
- It will be possible to receive relevant data every 20 minutes or more often.
KT.team worked only with the part of the client's business processes, which involved connecting to taxi fleet databases. How ATIMO receives information from automated inspection points, processes it and generates waybills is beyond the scope of the task.
Context
Before the flight, every taxi driver must receive a waybill with information about the driver's health and the condition of the car. To do this, the taxi fleet must either employ a doctor and mechanic, or use the services of third-party organizations.
ATIMO suggested that taxi companies simplify their interaction with contractors to obtain waybills. The startup provides its clients with access to automated points where doctors and mechanics work. The driver logs in to such a point using the phone number, then the doctor examines him, and the car is checked by a mechanic. All data is uploaded to the system, processed and, based on them, an electronic waybill is generated.
To generate a waybill, the ATIMO app needs data about drivers and cars:
- mobile phone number;
- Driver's name;
- his date of birth;
- driver's license details;
- vehicle registration certificate;
- OSAGO insurance policy number.
The app must connect to the taxi fleet database (DB) to pick them up.
One taxi company may have several databases. For example, different branches use different databases or the taxi fleet maintains a separate driver database and a car database. Each taxi company has its own rules for storing information: field names in tables and data formats may differ. This should be taken into account and all fields must be brought to a single form so that the system can process them.
The same data from different taxi companies is stored in different formats
Medical and technical examination logs and ready-made waybills are stored on the ATIMO server. If a taxi company needs to obtain this data, it connects to the server, logs in and downloads it.
The scheme of interaction between services before the start of the project
KT.team introduced a service bus for transferring data from taxi companies to ATIMO and back
KT.team has designed a new data transfer scheme so that the ATIMO system has one connection point left — the service bus (ESB). In other words, taxi companies can no longer connect directly to the ATIMO database to transfer or receive data. The security of interaction has increased for all participants in the scheme.
The bus connects to the taxi fleet database, downloads data about drivers and cars and uploads it to its own storage. From there, the data is sent to ATIMO.
Then ATIMO returns the finished waybills to the tire. ESB downloads them and uploads them to a second repository. After that, any taxi company can send a request to the tire and receive waybills for its drivers.
ESB formats data from the taxi fleet database to transfer it to the ATIMO system in a ready-to-process form. Mapping rules are configured within each service.
KT.team changed the solution architecture three times to achieve optimal results. In the first version, the bus interviewed all databases using a single service.
This approach saved server resources well, but was not fault-tolerant. Due to the fact that all requests went 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 was connected to each database through a separate service. This required slightly more server resources, but ruled out a massive failure due to one inaccessible database or another error.
In addition, this solution had many additional steps, for example, collecting and logging all errors. They required additional processing time and memory, so the architecture needed to be lighter and simpler.
The final version of the architecture is also based on separate services for each connection point.
All services work the same way:
- are connected to the taxi fleet database;
- download data;
- lead them to the format that the client's system uses;
- write new data to the repository;
- delete irrelevant data.
To add a new taxi fleet, you need to copy one of the existing services and configure it: for example, replace the mapping rules. To make this task easier for the customer, KT.team used Mule's low-code solution as the basis for the tire. This tool does not require programming skills, so any ATIMO employee can work with it.
In addition, KT.team has prepared a step-by-step instruction for setting up a connection point, which describes all the nuances.
results
- The service bus allowed ATIMO to connect 20 taxi fleets. These are 42 separate connection points, as many contractors have more than one database.
- The bus is connected to each taxi fleet through a separate service. Even if one of the services fails or the taxi fleet database is unavailable, this will not affect the data of other contractors in any way.
- Connecting to the taxi fleet database takes less than 1 second for most contractors.
- The whole process from connecting to a taxi fleet to uploading ready-made information to the ATIMO database takes a maximum of two minutes. Moreover, this value is true for the “slowest” contractors with outdated database management systems or low connection speeds.
- Separate services for each database and their simple operation scheme helped save server resources. Each request now requires 300-500 MB instead of 1-4 GB. You can connect to all taxi companies at the same time.
- Taxi companies do not connect directly to ATIMO, so there is no risk that the client's system will be hacked through a poorly protected counterparty database.
- The system is easy to scale. The client itself copies and sets up new connection points according to the instructions. A person with no development experience can add a taxi fleet in a couple of hours.
.png)
.png)
