Comment Tinder est passé à 1,6 milliard de balayages par jour

"Il était une fois un étudiant nommé Kenji à Okinawa, au Japon.

Kenji ; Architecture d'amadou Il déménage en Australie pour des études supérieures.

Mais un jour, sa petite amie rompt avec lui.

Alors il était triste.

Il entend parler d'une plateforme de mise en relation appelée Tinder.

Bien qu'introverti, il décide de l'essayer.

Voici une version simplifiée de l'architecture Tinder :

Chapitre 1 : Surmonter la rupture Kenji crée un profil Tinder et ajoute des informations supplémentaires.

Ils stockent les informations utilisateur dans une base de données clé-valeur comme Amazon DynamoDB. Et utilisez Dynamo Streams pour transférer automatiquement les modifications d'une table vers différents emplacements.

Les informations utilisateur sont également ajoutées à la file d'attente des messages pour mettre à jour l'index d'emplacement. Ils utilisent l'index de localisation pour trouver efficacement les utilisateurs à proximité.

Ils fournissent des API publiques via une passerelle API. Cela signifie qu'il agit comme un point d'entrée central pour les demandes des utilisateurs vers l'infrastructure. Et gère l'autorisation des utilisateurs et les règles de sécurité.

Ils gèrent environ 500 microservices. Et utilisez le maillage de services pour communiquer entre les services. Imaginez le maillage de services comme une infrastructure réseau permettant de gérer efficacement la communication des microservices.

Chapitre 2 : La dame d'Okinawa Kenji voit les profils Tinder des personnes vivant à proximité.

Il est difficile de trouver des personnes à proximité uniquement sur la base des valeurs de latitude et de longitude d'une personne.

De plus, ils ne divisent pas la carte du monde en grilles régulièrement espacées pour éviter le problème des fragments chauds. Parce que les grilles dans l'océan seront vides. Tandis que les réseaux des grandes villes compteront de nombreux utilisateurs. Un fragment chaud représente une charge excessive sur une seule partition.

Au lieu de cela, ils utilisent la bibliothèque S2. S2 est un système d'indexation géospatiale hiérarchique de forme carrée créé par Google.

C'est une bibliothèque stable prenant en charge de nombreux langages de programmation. En d'autres termes, ils utilisent S2 pour recommander des personnes en temps réel et partager la base de données de localisation.

S2 divise la surface de la Terre en cellules sur une grille plate, donnant à chaque cellule un identifiant unique avec un entier de 64 bits. En d'autres termes, une petite cellule représente une petite zone de la Terre.

Ils stockent les utilisateurs physiquement plus proches les uns des autres dans la même partition de base de données. Réduisant ainsi le besoin d'interroger de nombreux fragments pour trouver des utilisateurs à proximité.

Et S2 est hiérarchique. Cela signifie que la taille des cellules varie de centimètres carrés à kilomètres carrés.

Il prend également en charge la recherche d'une cellule spécifique en utilisant la latitude et la longitude. Et fournit la fonctionnalité permettant de trouver les cellules environnantes d'une cellule spécifique.

S2 est basé sur la courbe de Hilbert. Imaginez la courbe de Hilbert comme une ligne qui couvre chaque point d'un carré en se pliant et en bouclant d'une manière spéciale. Alors que deux points proches sur la courbe de Hilbert le sont également dans l'espace physique. Cela signifie qu'il préserve la localité spatiale.

Chaque petite courbe de Hilbert représente une cellule S2. Alors que quatre cellules adjacentes forment une cellule plus grande, et un quadtree représente une courbe de Hilbert 2D. Un quadtree est une structure de données arborescente dans laquelle chaque nœud a exactement quatre enfants.

Ils interrogent l'index de localisation (S2) pour trouver les utilisateurs à proximité. Il renvoie tous les fragments de base de données proches d'un emplacement spécifique. Après cela, ils interrogent en parallèle toutes les partitions de base de données pertinentes pour obtenir la liste des utilisateurs dans ces partitions.

En moyenne, ils interrogent 3 fragments de base de données pour trouver les utilisateurs à proximité dans un rayon de 160 km. Ils filtrent également les résultats en fonction des préférences des utilisateurs avant de recommander des personnes.

Kenji rencontre une dame d'Okinawa.

Mais cela n'a pas fonctionné car elle n'était pas intéressée par une relation à distance.

Chapitre 3 : D'Okinawa à Sydney Kenji pensait qu'une correspondance sur Tinder avec quelqu'un à Sydney, en Australie, aurait plus de sens.

Il utilise donc la fonctionnalité de Tinder appelée Passport pour changer de position.

Modification de l'emplacement de l'utilisateur

Ils mettent à jour l'index sur les changements de localisation des utilisateurs. Ainsi, les personnes du nouvel emplacement pourraient voir l'utilisateur. En d'autres termes, ils ajoutent l'utilisateur au nouvel index d'emplacement et suppriment l'utilisateur de l'ancien index.

Mais ces opérations ne sont pas atomiques, il y a donc un risque d'échec.

Jusqu'au jour où Kenji a mis à jour le profil vers le nouvel emplacement. Et revient immédiatement à l'emplacement d'origine. Mais ses données utilisateur indiquaient toujours le nouvel emplacement car les opérations n'étaient pas exécutées dans le même ordre.

Le problème sans commande garantie

Ils utilisent donc Apache Kafka pour résoudre ce problème. Considérez Kafka comme une plateforme de streaming distribuée pour le traitement de données à grande échelle.

Ils ont envoyé les mêmes données utilisateur aux mêmes partitions Kafka. Tandis que les consommateurs Kafka acquièrent des verrous sur les partitions pour éviter les conflits. Offrant ainsi une implémentation de file d'attente FIFO avec des garanties de commande et un débit très élevé.

Ils vérifient également le point Kafka afin que le traitement puisse reprendre après un crash de processus.

Chapitre 4 : Zoé et Kenji Kenji n'arrêtait pas de swiper sur Tinder.

Et les jours passèrent.

Utilisateurs correspondants

Ils envoient des balayages à un flux de données comme Amazon Kinesis. Et exécutez des Match Workers pour lire le flux de données et vérifier s'il existe une correspondance dans le cache J'aime.

Tandis que le cache J'aime stocke les informations sur les personnes qu'un utilisateur a aimées.

Informer les utilisateurs d'une correspondance

Ils utilisent WebSockets pour informer les utilisateurs en cas de correspondance. Donnant ainsi une expérience en temps réel. WebSockets est un protocole de communication bidirectionnel en temps réel.

Stockage des profils détestés par un utilisateur

Ils placent les profils détestés par une personne dans un stockage de données comme Amazon S3. Et utilisez ces informations pour l'analyse des données afin d'améliorer les recommandations des utilisateurs.

Jusqu'au jour où. Kenji est jumelé à Zoé.

Une dame de Sydney.

Chapitre 5 : Les problèmes sont des lignes directrices Ils calculent le nombre unique d'utilisateurs pour trouver la charge sur un fragment. Et les utilisateurs d'une partition se trouvent généralement dans le même fuseau horaire.

Le modèle de trafic de deux fragments différents

Un problème de partition chaude se produira probablement en raison des différences de fuseau horaire. Cela signifie que le trafic de pointe différera selon les endroits en raison du décalage horaire. Et provoquent un trafic déséquilibré entre les fragments.

Pourtant, un seul fragment sur un serveur physique ne ferait qu'empirer les choses. Ils attribuent donc de manière aléatoire de nombreux fragments au même serveur physique pour éviter le problème des fragments chauds.

Mise en cache pour éviter les problèmes de fragments chauds

De plus, la plupart des opérations de données sur Tinder sont des opérations de lecture. Ils utilisent donc le cache Redis à des fins d'évolutivité.

Ils utilisent le modèle de cache-aside. En d'autres termes, ils vérifient les données dans le cache. Et s'il est absent, ils reviennent à la base de données. Le cache est également mis à jour avec les données.

Ainsi, la couche de cache résout le problème de lecture des fragments chauds. Bien qu'ils limitent le débit pour gérer le problème d'écriture à chaud.

En outre, ils effectuent un recul exponentiel avec gigue en cas d'échec. Et exécutez périodiquement un travail en arrière-plan pour synchroniser les magasins de données.

Tinder reste l'une des plus grandes plateformes de rencontres. Et gérez environ 26 millions de matchs par jour.

Tandis que Kenji et Zoé vivaient heureux pour toujours.

"

Veuillez noter que la version française est assistée par Ai, des erreurs mineures peuvent donc exister.

Auteur

AiUTOMATING PEOPLE, ABN ASIA a été fondée par des personnes ayant des racines profondes dans le milieu académique, avec une expérience professionnelle aux États-Unis, aux Pays-Bas, en Hongrie, au Japon, en Corée du Sud, à Singapour et au Vietnam. ABN ASIA est l'endroit où l'académie et la technologie rencontrent l'opportunité. Avec nos solutions de pointe et nos services de développement logiciel compétents, nous aidons les entreprises à se développer et à s'imposer sur la scène mondiale. Notre engagement : Plus vite. Mieux. Plus fiable. Dans la plupart des cas : moins cher également.

N'hésitez pas à nous contacter chaque fois que vous avez besoin de services informatiques, de conseils en matière de numérique, de solutions logicielles prêtes à l'emploi, ou si vous souhaitez nous envoyer des demandes de propositions (RFP). Vous pouvez nous contacter à l'adresse [email protected]. Nous sommes prêts à vous aider avec tous vos besoins technologiques.

© ABN ASIA