Contact us for a personal offer on FinMV that is customized to your needs.
CTO of your company, when planning the launch of a financial platform, will have to choose the project architecture option. What architecture options are available to him, and which one is better to choose?
Monolithic architecture can be compared to a snowball. You start making a project and you have a small snowball. It is so small that it can be developed and rolled by a small team. A couple of years passed, and now your snowball has become so huge that it is already being pushed by 20 developers. It will take another couple of years, and hundreds of developers will roll your snowball with a ton of program code, but the launch of new features will become very slow.
As a result, the owners begin to change CTO, team members, but it only gets worse. The new team members do not know the historical specifics of why the snowball is exactly like this and not another. The product documentation quickly becomes outdated.
Why not initially do it right away? Firstly, at the very beginning of a business, resources are always limited, there are not enough developers, expertise, and time. The management is adjusting, and programmers are rushing to do it in the fastest way possible.
Secondly, technical engineers think: "Well, let there be a monolithic architecture for now, but when the business grows, then we will redo everything". Unfortunately, it will be ten times more difficult to transfer an existing monolithic project to a microservice architecture than to write it all over again "from scratch".
We will make your financial platform immediately based on a microservice architecture.
Microservice architecture can be compared to paving slabs on pedestrian paths. As your project grows, more and more tiles are added to your footpath. If some component is outdated, it is enough to replace this tile with a new one.
There are many advantages of such an architecture, but I will name the most important ones:
The first example. The management of the P2P lending platform with many users decided to enter the markets of countries with a different currency. The platform had a monolithic architecture and only one currency was embedded in it - the euro, and to enter the markets of Sweden (Swedish krona), Poland (Polish zloty), the Czech Republic (Czech crowns), it was necessary to introduce multicurrency.
It took months for the whole team to implement such functionality, and the development of new functionality slowed down even more. In the case of microservice architecture, everything would be much easier and faster.
The second example. Initially, the website builder was launched in the native language and the management was not going to enter other markets. The project had a monolithic architecture, and the functionality grew rapidly. The scheme of the platform was a complex web in which everything was connected to everything. One day, the business decided to release a version of the platform in other languages. At first, it seemed that it was enough to add only language files and now the entire interface will be translated.
In practice, the whole project had to be redone. For example, the names of companies and products in the database should now be stored not only in one language but in each language. It was impossible to duplicate the information because of business logic, it was necessary to store the names for all languages at once. Accordingly, this caused changes to the portal and back-office interfaces. Changing the interface required changing the rules for validating incoming data, letter templates due to different principles of endings in different languages, changing tests, etc.
Since everything was connected to everything, it was decided to switch to a microservice architecture along with the launch of new languages. The process of transition from monolithic to microservice architecture took more than a year.
The third example. The fintech platform was made on an old version of PHP and Laravel. The transition to newer versions, as well as the change of the database from MariaDB to PostgreSQL, was virtually impossible since the entire team had to deal with the migration process only for several months.
New versions of PHP and Laravel at that time could have accelerated the work of the project and further development, but the monolithic architecture did not allow updating the technology stack.
.
