The choice of architecture solutions for the marketplace of freight services

  • Tutorial is the first service in Russia for online pricing and ordering of air, road and container transportation, general cargo by all modes of transport, including door-to-door rates.


Dmitry Dolgikh, project manager of Reksoft (part of Technoserv Group of Companies), tells about the history of the Agorafreight project.

Russian startup Agorafreight is a marketplace for international cargo transportation, which is designed to calculate the cost of freight services provided by forwarding companies and carriers. The system is a link between the customer of the carriage (the client), shipping companies and freight forwarders. The system allows you to pre-select the route, companies and services, as well as the calculation of the cost of transportation.

The project itself is very interesting and ambitious. Interesting at least because there is no such decision in Russia yet. The word “international” gave the project ambiguity - on the one hand, the project’s ambitions in terms of scaling to the whole world were declared, and on the other, we understood that the project had to pave the way in a fairly competitive environment. A part of such an environment is always the project’s ability to respond quickly to changes and unexpected reversals in terms of requirements. All this immediately set a certain level of responsibility in the choice of the solution architecture, all the more so as there was not enough time to implement the first version of the product.

First we had to choose a database, or rather a data management system. The choice fell on MongoDB - the document-oriented NoSQL database with support for geo-queries, full-text search in 15 languages, with a hierarchical data structure. The MongoDB system is available for free under the GNU 3.0 license. It scales horizontally and can be used as load-balanced file storage and data replication.

  1. Hierarchy of data - the ability to optimize the scheme and requests for hierarchical data (multilingual, tariffs, etc.).
  2. Schema-less, non-rigid data schema - cheap and fast changes in the database schema, which does not require migrations.
  3. Scalable - it is cheaper than the relational database, does not require processing the source code or rewriting queries to the database.
  4. Support geo-queries and indexes, full-text search.
  5. An open source open source system.
  6. It is possible to buy paid support from the authors of MongoDB, enterprise support.
  7. MongoDB can be used as load-balanced file storage and data replication.
  8. With MongoDB, it is easier and faster to prototype applications and services.

1. There is no support for Join'ov, however this problem is solved by the data hierarchy or MapReduce-functional (but not 100%).

  1. There are no transactions, there is atomicity at the document level, you can implement transaction emulation.
  2. The consistency at the database level is not implemented, it is necessary to do this in the source code of the application.
  3. There are no triggers as in classical databases, however often this functionality is not used.


  1. MongoDB does not require administration at the start and a little after it, a setting is required for scaling.
  2. There are hosting providers that can provide MongoDB in the cloud for the desired scale, such services are rarely found in MySQL or PostgreSQL.
  3. The leader among NoSQL-data warehouses at the moment.
  4. It has tools for building MapReduce queries that can be used to build complex reports, but not in real-time.
  5. The critical shortcomings of this database were resolved with the release of the 3rd version.

The team made a choice in favor of the MongoDB based on the analysis of the project. Initially, it was clear that the project is characterized by a high probability of variability in terms of setting technical specifications on the basis of business processes. This is due to the fact that the project is a startup, so it is highly probable that many business processes will change in the course of project implementation and its adaptation to the realities of market demands. To ensure the flexibility of changes and reduce internal costs of changing the data model, as well as reduce their own risks, a choice was made in favor of a non-relational database. One of the leaders in this segment is MongoDB.

This choice, as shown by subsequent practice, proved to be correct. Everything happened as it was supposed to - permanent changes in the formulation, improvements from the series “and we still wanted to realize it”, and all this required a flexible and operative change of the data model. MongoDB allowed the project not only to adequately respond to changes, but also not to “fall out” from the budget. As is well known, defects at the design stage lead to substantial reengineering in the implementation and increase in the risk of missing within the deadlines and in the project budget. All these risks were minimized, including due to the selected architecture.

The second architectural choice was the ReactJS library for the implementation of the frontend. It is the popularity of technology and a large formed community made it possible to make a choice in favor of ReactJS.

Advantages of this framework:

  1. One of the most popular client development frameworks. It has a large community, there are many examples of its use, good documentation.
  2. Those developers of our company who have experience with him speak well of him.
  3. More flexible in terms of development in comparison, for example, with Angular.
  4. Supports the so-called Server Rendering, which allows you to index application pages by search engines.
  5. Suitable for applications with a large number of dynamic pages. We have many such pages (entry forms for various types of tariffs, surcharges, fees; forms for calculating the cost of transportation, etc.)

As a result, ReactJS allowed to change parts of the frontend quite flexibly and dynamically against the background of changing requirements and improvements.

In the course of the project, in addition to developing, it was necessary to solve algorithmic and optimization problems of drawing up an optimal transportation plan, comparing and building hundreds of variants of delivery routes with the selection and formation of the most optimal recommendations. And in this vein, the project has a high potential for development in the direction of recommender systems based on artificial intelligence.
In general, despite all the difficulties that arose in the process of developing a project, it was interesting from the point of view of using modern and promising technologies for developing information systems for the international transportation market.

Currently, the system contains tens of thousands of current tariffs for sea, road and air transportation. The geography of coverage covers China, Vietnam, South Korea, the EU countries and Russia, it is planned to expand to other countries. Now dozens of freight forwarders from China and the Russian Federation are already working with the system.


Also popular now: