Prêt de voiture d'occasion en 1 minute

Au lieu d'introduire

Comme toutes les histoires intéressantes, celle-ci a commencé il y a longtemps et de manière inattendue. Une fois que notre banque partenaire est venue nous voir et nous a dit: «Les gars, nous avons appris à faire des scores dans notre système en une minute. Que diriez-vous d'unir vos forces et d'intégrer des projets? Avec nous - une décision et un crédit, avec vous - des voitures. » Dire que nous étions inspirés - ne rien dire! Nous avons eu toutes les chances de devenir le premier presque au monde à pouvoir accorder un prêt en ligne pour une voiture d'occasion en une minute (UNE MINUTE, CARL)! Ci-dessous, je vais vous dire ce qui en est ressorti, mais je vais d'abord vous dire qui nous sommes, en fait, NOUS.

Nous sommes «Roues | Toit | Market »est la plus grande entreprise informatique basée au Kazakhstan. Chaque jour, nos produits aident six millions de Kazakhstanais à acheter et vendre des voitures, des appartements, des berceaux et des milliers d'autres choses. Kolesa.kz est la plus grande ressource et application automobile; elle occupe depuis plusieurs années la première place dans la notation mobile du Kazakhstan.

Qu'est-ce que le projet «Prêt de voiture»?

À l'heure actuelle, la base des voitures d'occasion est de 103 400 voitures, dont plus de 60% sont disponibles à crédit!

Vous rappelez-vous comment tout a commencé ...

Tout était pour la première fois et encore! Si, plus tôt, nous avions simplement un formulaire de rétroaction comme formulaire de crédit, alors notre nouvelle idée était quelque chose de complètement nouveau et incompréhensible. Parce que Nous n'avions pas d'analogues, nous avions une tâche très excitante à accomplir - planifier, concevoir, distribuer et mettre en œuvre. Dans un premier temps, nous avons divisé l'ensemble du processus de notre intégration commune en 2 blocs, qui se sont déroulés en parallèle, à savoir:

• Intégration d'infrastructure

• Intégration de logiciels

  
  

  Initialement, nous avons convenu avec la banque partenaire qu'il (la banque partenaire) nous fournira une sorte d'API, dans laquelle nous enverrons des données et recevrons des réponses. Ils ont décidé de cela. Nous avons commencé à attendre la documentation de l'API de la banque, réuni nos et leurs ingénieurs réseau! En termes d'intégration logicielle, un schéma assez simple a émergé, nous envoyons des données à la banque, la banque les fait défiler dans son système, et nous les restitue, et tout cela pendant 60 secondes garanties. En cas de dépassement de délai (où cela pourrait-il se passer sans cela), nous avons convenu d'afficher un questionnaire d'urgence, dans lequel nous obtenons des données dont la banque pourrait avoir besoin en plus.

  
  

Réseaux

A cette époque, alors que les développeurs choisissaient des outils pour l'implémentation, ils concevaient leur système et attendaient la documentation sur le système partenaire, le travail au sein du département infrastructure battait déjà son plein! Ma banque partenaire et moi en avions deux: 2 cisi se tenant côte à côte dans un DC, un câble reliant tsiska, un tunnel VPN, des certificats de sécurité et pribludy pour travailler avec eux de toutes les couleurs et de toutes les tailles ... Le plan était le suivant, nous transmettons le canal VPN crypté entre nos serveurs, et construire une intégration directe entre nos services. Schématiquement, cela peut être représenté comme suit:

Parlons du code

Ci-dessous, nous parlerons de la manière et de ce qui est organisé par notre service. Ainsi, après avoir reçu un document décrivant le service du partenaire prêt à être intégré, nous avons appris que, contrairement à nous, la banque ne fonctionne qu'avec les demandes SOAP et ne souhaite pas entendre parler de services RESTful. Et comme dans nos services, nous utilisons le SAVON un peu moins souvent que jamais, nous avons eu beaucoup de découvertes merveilleuses sur la façon d'apprendre à préparer du SAVON dans notre nouveau produit. Par conséquent, nous devions apprendre à notre service à analyser les demandes SOAP et à reconvertir nos réponses en SOAP.

Sélection du cadre

Pour commencer, il fallait choisir au moins un langage d'implémentation, il y avait beaucoup d'idées, à commencer par C et C # se terminant par golang et erlang. Nous avons décidé de suivre un chemin simple. Le système devra être pris en charge, et afin de ne pas se heurter au facteur bus avec un manque de spécialistes sur le marché, nous avons décidé de nous concentrer sur la technologie la plus courante dans notre entreprise - PHP. Dieu merci, en dehors de la fenêtre, ce n'était pas déjà 2001, mais 2017 et il y a tellement de frameworks php qu'ils peuvent satisfaire les besoins d'ingénieurs même très sophistiqués. Après avoir parcouru tout un tas, nous avons choisi l'un des plus simples et en même temps pris en charge - Yii 2.

Car cette décision était:

• Facile à maîtriser, tout un tas de littérature;
• Il est assez facile de créer des formulaires et des validateurs;
• Il y a un Active Record et une voiture prête à fonctionner avec toutes sortes d'outils;
• Il est vraiment rapide;
• Sur cette base, une API est simplement construite, il est pratique d'écrire des commandes de console.

Contre était:

• Le framework est construit sur des méthodes statiques - cela est très gênant, y compris lors de l'écriture de tests
• Il n'était pas clair de quels outils supplémentaires nous aurions besoin dans un proche avenir après le lancement, et, par conséquent, il y avait un risque de ne pas trouver les bibliothèques nécessaires ...

Sélection de stockage

Le framework a été choisi, il est maintenant temps de choisir un référentiel pour les applications. Il y avait plusieurs options, MySQL, mongoDB, postgreSQL ... D'une part, une application est un document, à coup sûr sa structure peut changer, ponctuellement complétée par de nouveaux champs et se débarrasser de ceux non pertinents. En revanche, l'utilisation de bases de données non relationnelles imposera ses limites. Après avoir pesé le pour et le contre, nous avons décidé de nous asseoir sur 2 chaises et d'utiliser MySQL pour lancer, et après le lancement, nous migrons vers un tas de mongoDB + ElasticSearch. En conséquence, 2 répliques MySQL ont été générées en tant que stockage et vissées à l'application à l'aide d'ActiveRecord. Au moment où nous avons commencé la transition vers mongoDB, la quantité de données a beaucoup augmenté et a pris un taux de croissance tel qu'il y avait un autre besoin de diviser les applications en référentiels conditionnels. En tant qu'outil d'indexation de documents en temps quasi réel, ElasticSearch a décidé d'utiliser un service écrit en Golang - monstache.

Construction d'infrastructures

Nous avons décidé de faire l'infrastructure suivante: 10 backends avec l'application par le processeur d'application, 2 équilibreurs, 2 répliques MySQL, 3 fragments Elasticsearch, 3 répliques mongoDB et 2 répliques de service monstache.

Le processus

En général, le processus de prêt automobile peut être divisé en 2 parties:

1. Pour commencer, vous devez trouver une voiture adaptée, disponible à crédit. Vous serez probablement guidé par son état et les conditions du prêt.
2. Après avoir sélectionné une voiture, vous devez obtenir une approbation de prêt, pour cela, vous devrez remplir une demande

Concernant l'implémentation de la deuxième partie, nous avons plus ou moins décrit ci-dessus, parlons de l'implémentation de la première partie. La mise en œuvre de la première partie comprend plusieurs sous-parties:

1. Lors de la recherche d'une voiture, une personne doit pouvoir se concentrer, en plus des paramètres techniques, sur la disponibilité d'une voiture à acheter à crédit et sur le montant minimum d'un paiement mensuel. Pour ce faire, nous devons savoir au moment de l'annonce que la voiture est disponible à crédit et quel sera le paiement minimum pour celle-ci.
2. Après qu'une personne a choisi une voiture, nous devons lui fournir un calculateur de prêt, où il pourrait choisir la taille de l'acompte et la durée du prêt, choisissant ainsi le montant du paiement mensuel le plus confortable.

À cet effet, un microservice spécial dans la langue go a été développé. Son essence était la suivante: lorsqu'une annonce est soumise au microservice, un objet contenant toutes les données sur la voiture est envoyé, le microservice, basé sur les règles qui sont écrites séparément pour lui, renvoie le paiement mensuel minimum pour l'indexation dans la recherche, et renvoie également l'acompte minimum et les délais acceptables les prêts, qui sont la base de la construction d'un calculateur de prêt.

Nous mettons en cache les options de calcul erroné à l'avance pour les valeurs d'acompte standard et de paiement mensuel. Cela se fait pour chacune des périodes de crédit disponibles. Si une personne modifie le paiement initial (dans la plage acceptable), le microservice calculera à nouveau toutes les données. Si le paiement initial est spécifié inférieur au montant autorisé, la calculatrice affichera une erreur de validation.

En raison de la charge élevée sur notre service, le calculateur de prêt a 2 degrés de mise en cache: le premier a lieu sur le backend, où les clients choisissent initialement la calculatrice, le second dans le microservice lui-même.

Alors, quel est le résultat net?

Nous avons lancé le projet le 11 septembre 2017. Depuis ce moment, à ce jour (4 décembre 2018), 2 973 868 demandes ont été déposées. Nous sommes dans un processus continu d'amélioration de notre service et de simplification du parcours utilisateur. Nous le rendons plus rapide, plus facile et plus stable! Le temps de disponibilité du projet pour toute la période écoulée depuis le lancement était de 99,99%.

En conséquence, nous avons les résultats suivants:

1. Chemin utilisateur considérablement réduit
2. Nous avons augmenté le volume de voitures disponibles pour le prêt à 60% de la base entière
3. À ce jour, le nombre de demandes a augmenté de plus de 7 fois!

Au lieu d'une conclusion

En 3 mois, nous avons réussi à construire un projet vraiment incroyable et unique. Son objectif principal était de donner à nos clients la possibilité d'acheter des voitures d'occasion sans quitter notre plateforme. En seulement 1 minute, l'utilisateur peut prendre une décision sur sa demande, appeler le vendeur et établir tous les documents nécessaires le même jour.
A en juger par le nombre de demandes pour l'année et 2 mois, nous pouvons conclure que nous sommes en mesure de rendre le service vraiment pratique et en demande.