Concevoir WhatsApp : architecture et principes

Les particularités de WhatsApp : l’application permet d’envoyer des messages groupés et elle dispose d’un système de confirmation de lecture. Ce sont donc les deux fonctionnalités clés que les gens recherchent lors d’un entretien classique sur la conception de systèmes. Mais il existe également d’autres fonctionnalités dont nous allons parler, ainsi que celles que nous ne devrions probablement pas aborder lors d’un entretien, et nous choisirons essentiellement le type de choses que nous faisons afin de pouvoir réellement terminer dans l’heure qui nous est impartie.

Parmi toutes les fonctionnalités que vous pouvez demander à votre interlocuteur, aimeriez-vous ceci ? Aimeriez-vous cela ? Vous devriez probablement commencer par des choses simples et que vous connaissez déjà, car j’ai remarqué que la première fonctionnalité que vous demandez à votre interlocuteur est généralement acceptée. L’une des choses avec lesquelles je suis à l’aise est la messagerie de groupe. WhatsApp permet de créer des groupes pouvant accueillir jusqu’à 200 personnes, et je comprends donc assez bien le fonctionnement de la messagerie de groupe.

Le partage d’images est une autre bonne question à poser

Les images vont-elles être partagées dans ces messages ? La réponse est presque évidente : oui, nous autoriserons le partage d’images ou de vidéos. C’est également une bonne question, mais je veux dire que si vous avez déjà utilisé WhatsApp, vous savez ce que sont les accusés de réception, les confirmations de livraison et les confirmations de lecture. Vous voyez donc apparaître ces coches en fonction de l’état d’avancement du message.

Les deux derniers points ne sont pas essentiels pour une application en termes de fonctionnalités, mais il est intéressant d’y réfléchir d’un point de vue technique. La première est de savoir si la personne est en ligne. Si ce n’est pas le cas, quand a-t-elle été vue pour la dernière fois sur le chat ? La deuxième est de savoir si les chats sont temporaires ou permanents. Si vous regardez Snapchat, ou même WhatsApp, vous constaterez qu’ils sont beaucoup plus temporaires que la plupart des applications de messagerie professionnelle.

La raison en est que vous souhaitez préserver votre vie privée. Vous voulez donner beaucoup de pouvoir à l’utilisateur. De plus, cela permet de gagner beaucoup d’espace de stockage si l’on considère que les chats sont stockés uniquement dans les applications de l’utilisateur. Mais si vous devez respecter certaines règles de conformité ou s’il s’agit d’une communication officielle, vous souhaitez que ce message soit stocké quelque part pour toujours. C’est donc une autre question que nous allons poser. Bien que WhatsApp ne vous offre, pour ainsi dire, que des discussions temporaires, si vous supprimez l’application et que votre ami la supprime également, ces messages sont perdus à jamais.

Il vous reste donc quatre fonctionnalités pour cet article, et la première que nous allons aborder est la messagerie de groupe.

Avant d’aborder la messagerie de groupe

Avant d’aborder la messagerie de groupe, nous devons d’abord parler de la manière dont une personne envoie un message à une autre personne. Il s’agit donc d’une conversation en tête-à-tête, et c’est notre exigence, à savoir une conversation 1, 2, 1.

C’est ce à quoi nous allons venir, d’accord, procédons étape par étape. Beaucoup des éléments dont je vais parler ici se trouvent dans la playlist consacrée à la conception du système. Je vous invite donc à la consulter. Lorsque vous recherchez des éléments tels que l’équilibrage de charge ou les signaux de messagerie, je les utiliserai comme des abstractions, comme des structures permettant de répondre à toutes les fonctionnalités dont nous avons parlé. Si vous souhaitez obtenir plus de détails, vous pouvez toujours vous y rendre.

Le point de défaillance unique est également un élément très important dans l’architecture WhatsApp. Jetez-y un œil. Maintenant, commençons. Vous avez installé l’application sur votre téléphone portable. Vous vous connectez à WhatsApp sur le cloud. L’endroit auquel vous vous connectez s’appelle une passerelle. La raison en est que vous utiliserez un protocole externe lorsque vous communiquerez avec WhatsApp, mais WhatsApp pourrait communiquer dans un langage différent avec ses services internes.

La raison principale est que vous n’avez pas besoin d’autant de sécurité. Vous n’avez pas besoin des gros en-têtes que HTTP vous fournit lorsque vous communiquez en interne, car la plupart des mécanismes de sécurité sont pris en charge par la passerelle elle-même. Une fois que vous êtes connecté à la passerelle, supposons que vous envoyez un message à la personne B. Vous êtes donc la personne A et vous envoyez un message à la personne B. La personne A se connecte à la passerelle.

La passerelle doit en fait l’envoyer à la personne B. Vous pourriez stocker d’une manière ou d’une autre ces informations indiquant quels utilisateurs sont connectés à quelle boîte dans la passerelle elle-même. Dans ce cas, vous auriez besoin d’une sorte de mappage utilisateur-boîte. Pour le service de passerelle, qui est lui-même un microservice, il doit stocker les informations indiquant que cet identifiant utilisateur est actuellement connecté à la boîte numéro deux. Donc, s’il s’agit des boîtes numéro 1, 2 et 3, il faut disposer d’informations indiquant que B est connecté à la boîte numéro 2 et A à la boîte numéro 1.

Lorsque ce type d’informations est stocké sur les boîtes elles-mêmes, cela revient cher. Pourquoi ? Parce que le maintien d’une connexion, une connexion TCP, nécessite de la mémoire. Ce que vous voulez faire, c’est augmenter le nombre maximal de connexions que vous pouvez stocker dans une seule boîte et vous ne voulez pas que cette mémoire soit gaspillée en conservant des informations sur qui est connecté à quelle boîte.

Deuxièmement, ces informations sont dupliquées sur les trois serveurs. Soit elles sont dupliquées, soit il existe un mécanisme de mise en cache, soit il existe une base de données qui gère cela. Il s’agit d’informations transitoires, il y aura donc beaucoup de mises à jour à effectuer, ce qui n’est pas idéal. Je constate de nombreux couplages dans ce système.

Vous devez donc conserver une connexion « muette ». Cette connexion TCP doit être « muette » dans le sens où elle se contente de recevoir et de transmettre des informations, sans savoir ce qu’elle fait. En dehors de cela, la personne à qui vous devez vous adresser pour savoir qui est connecté à quelle boîte est un microservice en soi, et ce microservice peut être le microservice de sessions.

Que stocke un microservice de sessions ?

Eh bien, qui est connecté à quelle boîte ? Tout simplement les informations que nous stockions ici et qui étaient gérées par la passerelle ont été dissociées du système et envoyées au microservice de sessions. Vous pouvez voir qu’il existe plusieurs serveurs pour éviter les points de défaillance uniques.

Ainsi, lorsqu’un utilisateur envoie un message, il demande en fait d’envoyer un message avec l’ID utilisateur de B. Lorsque la passerelle reçoit ce message, elle est assez bête. Elle ne sait pas quoi faire, elle l’envoie simplement au service de session. Ce service de session est indirectement un routeur. Lorsqu’il reçoit ce message, lorsqu’il reçoit cette demande d’envoi de message à l’utilisateur B, il détermine où se trouve l’utilisateur B, à quelle boîte l’utilisateur B est connecté. Il achemine ensuite ce message en l’envoyant à la passerelle deux pour le renvoyer à l’utilisateur B.

À présent, A a envoyé un message à B. Intéressant. Comment A peut-il envoyer un message à B si le serveur envoie cette dernière partie où la passerelle deux envoie un message à B ? Cela ne peut pas être fait à l’aide du protocole HTTP. Il s’agit d’un protocole serveur-client. Je veux dire plutôt un protocole client-serveur. Le client envoie des requêtes, le serveur donne des réponses. Vous ne pouvez donc pas envoyer de message du serveur au client. Vous ne pouvez envoyer que des requêtes du client au serveur.

Il existe de nombreuses façons de contourner cela en utilisant HTTP lui-même. L’une d’entre elles est le long polling. Dans ce cas, toutes les minutes environ, B peut demander :

« Y a-t-il de nouveaux messages pour moi ? ».

Ensuite, la passerelle ou le service de gestion des sessions, selon votre préférence, peut lui envoyer le message. Bien sûr, ce n’est pas en temps réel. Et si vous voulez quelque chose en temps réel, en particulier pour les applications de chat, où le temps réel est très important.

Le protocole HTTP n’est donc pas adapté et nous avons besoin d’un autre protocole sur TCP. Ce que nous recherchons, ce sont des sockets Web. Les sockets Web sont très pratiques pour les applications de chat. La raison principale est qu’ils permettent une communication peer-to-peer. A envoie à B, B envoie à A, il n’y a pas de sémantique client ou serveur ici.

Ainsi, le serveur peut littéralement envoyer un message au client. B, d’accord, nous sommes donc satisfaits que B ait reçu le message. Et maintenant ? Eh bien, B a reçu le message. Cela signifie donc qu’il a été livré. À ce stade, l’utilisateur A devrait être informé que le message a été livré.

Il y a un point que j’ai oublié. Lorsque le message arrive à la passerelle et au service de session, il est possible d’envoyer une réponse parallèle à la passerelle 1 pour lui indiquer que le message a bien été reçu et qu’il sera envoyé à l’utilisateur B dès que possible. Imaginons une base de données différente pour le chat. Comme le message est stocké dans la base de données, il est en sécurité, il est persistant, et il sera réessayé jusqu’à ce que l’utilisateur B le reçoive.

A a donc la garantie que B va recevoir le message. Il devrait donc recevoir l’accusé de réception. Il suffit donc de répondre en disant : « OK, j’ai bien reçu le message, la passerelle 1 va maintenant envoyer le message à l’utilisateur A. » L’envoi est donc pris en charge lorsque tout ce flux est terminé.

Lorsque B reçoit le message pour la première fois, comment le livrer, comment fournir un accusé de réception ? Une fois que vous avez envoyé le message à B et que B a effectivement reçu le message, il doit répondre. Je veux dire qu’il doit à nouveau passer par la passerelle deux et dire qu’il a reçu le message. C’est un accusé de réception, un accusé de réception TCP. Lorsque la passerelle deux reçoit ce message, elle le renvoie au service de session en disant : « Hé, ce message a été reçu. Donc, ce message a été reçu. »

Le message contiendra les champs A deux et A de. Oui. Le service de session peut donc déterminer que le message a été reçu par la personne qui a été taguée ici, c’est-à-dire B. La personne qui a envoyé le message depuis A devrait donc recevoir un accusé de réception. Le service de session recherche à nouveau où se trouve A. Il s’agit de la case numéro un, qui envoie un accusé de réception. A reçoit un accusé de réception.

Et bien sûr, vous pouvez réfléchir à la manière dont la lecture va fonctionner. Dès qu’une personne ouvre l’application, celle-ci s’ouvre et affiche l’onglet de discussion. Elle envoie un message indiquant qu’elle a lu le message et le même processus s’applique également à la lecture.

La 2ème fonctionnalité que nous allons évoquer est assez simple

La deuxième fonctionnalité dont nous parlons est assez simple. Il s’agit de la dernière connexion ou de savoir si la personne est en ligne à ce moment-là. À grande échelle, c’est-à-dire à très grande échelle, lorsqu’il y a des millions d’utilisateurs, tout se complique. Mais l’un des principes architecturaux que nous pouvons appliquer ici est le suivant.

En termes simples, B veut juste savoir quand A était en ligne pour la dernière fois, et cette information doit être stockée quelque part. Le serveur pourrait demander à A, mais ce serait stupide. À la place, A n’est même pas dans le tableau, et les seuls messages qui seront envoyés et reçus proviennent de B et du serveur. B demande donc au serveur : quand A s’est-il connecté pour la dernière fois ?

Il faut qu’il y ait des informations dans un tableau indiquant que cet utilisateur s’est connecté pour la dernière fois à cette heure-là. Il faut donc un horodatage et il y aura une entrée ici avec un horodatage particulier. La seule question qui reste est de savoir comment cette ligne conserve l’horodatage de la dernière connexion d’un utilisateur particulier. Cette paire clé-valeur, chaque fois qu’un utilisateur A effectue une activité, essentiellement l’envoi ou la lecture d’un message ou toute autre requête au serveur, doit être enregistrée comme une activité et l’horodatage actuel doit être conservé dans ce tableau.

De cette manière, nous pouvons affirmer que chaque fois que A a effectué une action, il était certainement en ligne, ce qui signifie que l’horodatage de la dernière connexion doit être mis à jour en conséquence. B peut être informé si A est en ligne ou non. L’une des caractéristiques clés ici est que si A était en ligne il y a trois secondes, B ne doit pas être informé qu’il était en ligne il y a trois secondes.

Au lieu de cela, la balise affichée doit être en ligne. Il est probable qu’il n’ait effectué aucune activité au cours des trois dernières secondes.

Vous pouvez définir ce seuil comme vous le souhaitez, par exemple 10 secondes ou 15 secondes. Mais l’important est qu’il soit en ligne ou qu’il ait été vu pour la dernière fois il y a au moins 20 secondes. La balise « vu pour la dernière fois » est un peu difficile à mettre à jour, même après avoir pris en compte toutes les activités.

Je vais donc faire en sorte que chaque fois qu’un utilisateur envoie une requête à la passerelle, un microservice, qui est le microservice « vu pour la dernière fois », soit activé. Ce microservice assurera le suivi de l’activité des utilisateurs. Chaque fois qu’il y a une activité, un message est envoyé à la passerelle. Lorsqu’un message est envoyé à la passerelle, je vais considérer que l’utilisateur a été vu pour la dernière fois à ce moment-là.

Attention : Il peut y avoir des requêtes qui ne sont pas envoyées par l’utilisateur, mais par l’application elle-même. Par exemple, lorsque vous récupérez certains messages, vous êtes peut-être hors ligne, vous n’utilisez pas l’application, mais vous voulez que votre application vous avertisse chaque fois qu’il y a un message. Par exemple, l’accusé de réception n’est pas une activité de ma part. La requête doit donc être intelligente, en ce sens que le client doit être intelligent et dire qu’il s’agit d’une activité de l’utilisateur et que c’est quelque chose que l’application elle-même fait.

Il existe 2 types de messages envoyés par le client

1. L’un concerne les activités de l’utilisateur,
2. et l’autre concerne les messages générés par le système ou l’application.

Les requêtes de l’application

Cela peut être un indicateur dans la requête elle-même. S’il s’agit d’une demande d’application, ne l’envoyez pas au service « dernière connexion ». S’il s’agit d’une activité utilisateur, envoyez-la au service « dernière connexion », qui mettra à jour l’horodatage de la dernière connexion de cet utilisateur. De cette manière, l’utilisateur B peut savoir si l’utilisateur est en ligne, ou du moins à quelle heure il s’est connecté pour la dernière fois, en interrogeant ce service. La troisième fonctionnalité est donc également terminée.

Le service de session utilise sa propre base de données

En général, ces informations sont mises en cache autant que possible, mais il peut déterminer où ces utilisateurs sont connectés grâce à sa base de données. Je veux dire ces 10 utilisateurs. Il disposait d’un mappage entre l’ID utilisateur et la connexion. Et cette connexion vous indique dans quelle boîte, dans quelle passerelle il se trouve. Grâce à ces informations, il peut alors acheminer les messages vers chacun de ces utilisateurs, un par un.

Que se passe-t-il si le groupe compte trop de membres ? Dommage ? WhatsApp vous impose en fait une limite maximale de 200. De nombreuses applications de chat tentent de limiter ce nombre à 500 ou 600. La raison principale est que sinon, vous disperseriez trop la demande. Lorsqu’une célébrité publie quelque chose, cela revient à envoyer des messages à parfois des millions de personnes, ce qui n’est pas pratique.

Vous devez donc soit les traiter par lots, soit attendre que ces personnes les récupèrent. Dans une application de chat, vous voulez que les messages soient en temps réel autant que possible. Vous ne pouvez pas vraiment avoir trop de mécanismes de récupération.

Au lieu de cela, vous limitez le nombre de personnes dans un groupe. 200 est un nombre raisonnable par rapport à des millions. Oui, c’est un nombre très raisonnable.
Nous allons donc limiter le nombre d’utilisateurs à un nombre X, et nous allons supposer que les sessions peuvent gérer les sockets web qui envoient ces messages aux utilisateurs concernés.

Entrons maintenant dans les détails de ce mécanisme

Nous avons les grandes lignes, nous savons comment cela va fonctionner, mais les détails sont importants. La première chose que je ferais dans cette architecture, c’est que beaucoup d’utilisateurs vont se connecter à mes passerelles. Ces passerelles vont manquer de mémoire. C’est la raison pour laquelle nous avons séparé le service de session. C’est un bon moyen de réduire l’empreinte mémoire.

La deuxième chose que vous pouvez faire est de transmettre le message, n’est-ce pas ? Le message est peut-être envoyé via HTTP, il s’agit d’un message de chat, etc. Vous ne voulez pas vraiment transmettre le message converti en objet, faire des choses intelligentes dessus, vérifier s’il a été authentifié ou non sur la passerelle elle-même, toutes ces responsabilités, autant de responsabilités que possible, vous voulez les éloigner des passerelles car ce sont des sockets web. Elles sont coûteuses. Ce sont des utilisateurs réels connectés à votre boîte.

A lire aussi sur ce blog ⇒ Le chat vidéo aléatoire, une solution moderne pour ceux et celles qui cherchent un(e) partenaire pour des relations sérieuses

J’enverrais donc un message non traité au service de session ou à toute autre personne à qui je l’envoie. Une façon intelligente d’envoyer un message non traité à n’importe quel service est de faire passer ce message non traité par un microservice d’analyse syntaxique. Vous n’avez pas vraiment besoin de trop de serveurs, juste de serveurs suffisamment puissants. Je vais donc simplement l’appeler microservice d’analyse syntaxique et de désanalyse syntaxique.

Ce qu’il va faire, c’est prendre le message non traité et le convertir en un message compréhensible. Donc, si votre protocole interne est autre que HTTP ou écrit quelque chose ou TCP audio, vous avez quelque chose comme Thrift, qui est utilisé en interne par Facebook. Je dirais donc Thrift. Ensuite, vous pouvez transmettre le message ici même, n’est-ce pas ?

Quel est l’avantage ? Permettez-moi de revenir en arrière. Vous recevez un message électronique ici. Vous transmettez le message électronique, vous n’avez rien à faire sur la passerelle elle-même. Ce message électronique sera converti en un objet de langage de programmation compréhensible par ce parseur et ce déparseur. Il sera ensuite acheminé vers le bon endroit.

C’est donc une façon de réduire le ratio d’empreinte mémoire. Quels sont les autres points importants sur lesquels nous devons nous concentrer ? L’identifiant de groupe vers l’identifiant d’utilisateur ? Il s’agit d’un mappage un-à-plusieurs, n’est-ce pas ? Un groupe peut avoir plusieurs identifiants d’utilisateurs et, pour réduire considérablement la duplication des informations dont vous disposez, nous utilisons ce qu’on appelle le hachage cohérent. Nous devrions nous pencher là-dessus.

Le hachage cohérent vous aide à réduire l’empreinte mémoire sur les serveurs en ne déléguant que certaines informations à certaines boîtes. Le hachage cohérent vous permettra d’acheminer la requête vers la bonne boîte. Ce qui doit être acheminé sur l’ID de groupe.

Si vous acheminez la requête sur l’ID du groupe, cela vous permet de savoir qui sont les utilisateurs appartenant à ce groupe. Cela prend en charge le mécanisme d’acheminement dont nous disposons. Si le service de groupe tombe en panne à un moment donné, vous envoyez le message au boîtier, mais cela échoue. Que faire ? Vous pouvez réessayer, mais vous ne pouvez réessayer que si vous savez quelle requête vous devez envoyer ensuite.

L’un des mécanismes permettant d’y parvenir est la file d’attente de messages

Les files d’attente de messages sont intéressantes dans le sens où, une fois que vous avez envoyé un message à la file d’attente, celle-ci garantit que le message sera envoyé, peut-être maintenant, peut-être 10 secondes plus tard, peut-être 15 secondes plus tard. Ce sont des options configurables. Vous pouvez également configurer le nombre de tentatives.

Tout cela est configurable dans la file d’attente de messages. Si la file d’attente de messages ne parvient pas à envoyer le message, même après cinq tentatives, elle peut vous signaler l’échec. Vous transmettez l’échec au client en lui indiquant que vous n’avez pas pu envoyer ce message de groupe. D’accord, cela convient également. Mais le client doit être informé de l’échec ou de l’effacement.

Lorsque le service de groupe reçoit ce message, il peut envoyer une réponse indiquant qu’il a bien reçu les sessions de message, puis envoyer une réponse à la passerelle, et l’utilisateur qui a envoyé le message d’origine reçoit une coche indiquant que le message a été envoyé.

Les reçus de groupe lorsqu’il s’agit de messages livrés ou vus sont assez coûteux. La raison principale est que tout le monde doit dire « oui, j’ai reçu le message, j’ai reçu le message », puis finalement, cela doit revenir à cette personne. Nous n’allons donc pas nous lancer dans autant d’applications de chat. En fait, nous n’avons même pas cela. Donc, ça va.

Les dernières choses intéressantes en matière de messagerie instantanée ou de messagerie de groupe en particulier, c’est que vous avez besoin d’idempotence.

Cette architecture est en fait très résistante et, en tant que système de chat, elle fonctionne plutôt bien. Il existe quelques astuces que vous ne pouvez connaître que si vous avez déjà travaillé sur des systèmes de messagerie. Je vais donc vous donner quelques exemples. Par exemple, je viens de lire sur un blog que Facebook Messenger dépriorise les messages en cas d’événement majeur, comme le Nouvel An ou une fête, où il y a beaucoup de messages.

Tout le monde va se souhaiter un joyeux Noel, une bonne année, ce qui va mettre beaucoup de pression sur le système. C’est là qu’interviennent tous les principes de limitation du débit, qui consistent à ne pas prendre en compte les messages qui ne sont pas très importants. Ou parfois, vous supprimez simplement les messages au lieu de les supprimer. Je veux dire, la meilleure chose à faire est de déprioriser les messages.

Des éléments tels que la dernière connexion peuvent être ignorés. La fonctionnalité entière peut être ignorée. Ce message a-t-il été livré ? A-t-il été reçu ? Ces éléments ne sont pas aussi importants que l’envoi du message à l’utilisateur. La première chose pour le serveur est de recevoir le message et l’accusé de réception. C’est tout ce que l’utilisateur a besoin de savoir. C’est plus important que de savoir si la personne a lu le message ou non.

Ainsi, en dépriorisant les messages sans importance, vous maintenez le bon fonctionnement du système et vous obtenez de bons résultats au lieu de n’en obtenir aucun.

Questions fréquentes

Quelles sont les principales fonctionnalités de WhatsApp abordées dans cette conception de système ?

Les principales fonctionnalités abordées sont la messagerie de groupe (avec jusqu’à 200 membres), les accusés de réception d’envoi/de livraison/de lecture, le statut en ligne et l’horodatage de la dernière connexion, et le caractère temporaire ou permanent des discussions.

Pourquoi WhatsApp utilise-t-il des sockets Web plutôt que le protocole HTTP pour la messagerie ?

Parce que le protocole HTTP est basé sur des requêtes-réponses et ne prend pas en charge la communication en temps réel entre le serveur et le client, tandis que les sockets Web permettent une messagerie bidirectionnelle en temps réel, essentielle pour les applications de chat.

Comment le statut « vu pour la dernière fois » est-il mis à jour sans compromettre la confidentialité des utilisateurs ?

Seules les activités initiées par l’utilisateur (et non les demandes générées par le système, telles que les accusés de réception) déclenchent une mise à jour de la dernière heure de connexion via un microservice dédié, garantissant un suivi précis et respectueux de la vie privée.

Pourquoi la messagerie de groupe est-elle limitée à 200 utilisateurs dans WhatsApp ?

Afin d’éviter une diffusion excessive des messages, qui mettrait le système à rude épreuve, en particulier par rapport à des plateformes telles qu’Instagram qui peuvent devoir en envoyer à des millions de personnes, WhatsApp donne la priorité à la livraison en temps réel au sein de groupes de taille raisonnable.

Quel mécanisme garantit la livraison des messages même en cas de défaillance temporaire du service ?

Les messages sont conservés dans une base de données et acheminés via des files d’attente de messages qui gèrent les nouvelles tentatives, garantissant ainsi la livraison finale ou la notification claire de l’échec au client.

Références