Like all interesting stories, this one started long enough and unexpectedly. One day, our partner bank came to us and said: “Guys, we learned how to score in our system in one minute. How about combining our efforts and integrating projects? With us - a solution and a loan, with you - cars. ” To say that we were inspired - to say nothing! We had every chance of becoming the first one in the world who can give a loan online for a used car in one minute (ONE MINUTE, KARL)! Below, I will tell you what came out of it, but for a start I will tell you who we are.
We are “Wheels | Roof | Market ”is the largest IT-company based in Kazakhstan. Every day, our products help six million Kazakhstanis to buy and sell cars, apartments, cribs and thousands of other things. Kolesa.kz is the largest auto resource and application, not the first year it has been ranked 1st in the mobile rating of Kazakhstan.
At the moment, the base of used cars is 103,400 cars, more than 60% of them are available on credit!
Figure 1. Search engine lending available
Figure 2. Ad Page Screen
Figure 3. Credit calculator for ad
Figure 4. Loan application initialization form
Here we enter your mobile phone number Name and IIN (in Russia it would be an INN)
Figure 5. The form of confirmation of the phone number by entering SMS
Figure 6. The scoring process screen
Figure 7. Example of Car Loan Approval Screen
After the person receives approval of his application, the manager from the bank calls him back within 10 minutes and informs the person about what actions he needs to take further in order to issue a loan. Convenient, isn't it? Let's see how it was all implemented.
It was the first time and again! If earlier, as a credit form, we simply had a feedback form, then our new idea was something completely new and incomprehensible. Since We had no analogues, we had to have a very exciting experience - to plan, design, distribute and implement. To begin with, we broke the whole process of our joint integration into 2 blocks, which were performed in parallel, namely:
Software integration
Initially, we agreed with the partner bank that it (the partner bank) will provide us with some kind of API, to which we will send some data and receive some answers. On that and decided. We began to wait for API documentation from the bank, brought our engineers and their network engineers together! In terms of software integration, a fairly simple scheme emerged, we send the data to the bank, the bank scrolls through it in its system, and returns it to us, and all this within the guaranteed 60 seconds. In case of a timeout (where without it), we agreed to display an emergency questionnaire in which we collect data that the bank may additionally need.
At that time, while the developers chose the tools for implementation, designed their system and waited for the documentation on the partner system, in the infrastructure department the work was already in full swing! We had two partners with our partner bank: 2 adjacent tsiska in one DC, cable connecting tsiski, VPN-tunnel, safety certificates and access to work with them of all colors and sizes ... The plan was as follows, We pass the encrypted VPN channel between our servers, and build direct integration between our services. Schematically, this can be represented as:
Below we will talk about how and what is arranged by our service. So, having received a document describing the partner's service ready for integration, we learned that, unlike us, the bank works only with SOAP requests, and does not want to hear about any RESTful services. And since in our services we use SOAP a little less than never, we had many wonderful discoveries about how to learn how to prepare SOAP in our new product. Therefore, we needed to teach our service how to parse SOAP requests and convert our responses back to SOAP.
To begin with, it was necessary to choose at least an implementation language, there were a lot of ideas, starting with C and C # ending with golang and erlang. We decided to go on a simple path. The system will need to be maintained, and in order not to run into the bus factor with the lack of specialists in the market, we decided to focus on the most common technology in our company - PHP. Thank God that the window was no longer 2001, and the year 2017 and php frameworks are so numerous that they can satisfy the needs of even highly sophisticated engineers. After going through a whole bunch, we chose one of the simplest and at the same time supported - Yii 2.
For this decision was:
It was against:
The framework has been chosen; now it’s time to choose a repository for applications. There were several options, MySQL, mongoDB, postgreSQL ... On the one hand, the application is a document, for sure its structure can change, from time to time adding new fields and getting rid of irrelevant ones. On the other hand, the use of non-relational databases will impose its limitations. After weighing all the pros and cons, we decided to sit on 2 chairs and start using MySQL, and after starting migrate to the mongoDB + ElasticSearch bundle. As a result, 2 MySQL replicas were raised as storage and bolted to the application using ActiveRecord. By the time we started the transition to mongoDB, the amount of data has grown tremendously and has taken such a growth rate that there is another need to separate requests for conditional storage. As a tool for near-realtime document indexing, ElasticSearch decided to use a service written in Golang - monstache.
The infrastructure decided to do the following: 10 backends with an application request handler, 2 balancers, 2 MySQL replicas, 3 elasticsearch shards, 3 mongoDB replicas and 2 monstache replicas of the service.
In general, the process of car loans can be divided into 2 parts:
We have more or less told about the implementation of the second part, we will talk about the implementation of the first part. The implementation of the first part consists of several parts:
For this purpose, a special microservice in the go language was developed. Its essence was as follows: When submitting an advertisement, an object is sent to microservice with all the vehicle data, microservice, based on the rules that are written separately for it, returns the minimum monthly payment for indexation in the search, and also returns the minimum initial installment and allowable time credits that form the basis for building a loan calculator.
We pre-cache the miscalculation options for the standard values ​​of the initial payment and the monthly payment. This is done for each of the available credit periods. If a person changes the initial payment (within the limits of the allowable), then microservice will again calculate all the data. If the initial payment is specified less than the allowable, the calculator will display a validation error.
Due to the high load on our service, the loan calculator has 2 degrees of caching: the first occurs on the back end, where customers initially go for the calculator, the second in microservice itself.
We launched the project on September 11, 2017. From the moment on today's date (12/04/2018) 2,973,868 applications have been submitted. We are in a continuous process of improving our service and simplifying the user path. Making it faster easier and more stable! Uptime of the project for the entire period since launch was 99.99%.
As a result, we have the following results:
For 3 months we managed to build a truly amazing and unique project. Its main goal was to give our customers the opportunity to purchase used cars without leaving our platform. In just 1 minute, the user can get a decision on his request, call the seller, and arrange all the necessary documents on the same day.
Judging by the number of applications per year and 2 months, we can conclude that we manage to make the service really convenient and in demand.
Source: https://habr.com/ru/post/431342/