To push or not to push : les grandes erreurs algorythmiques - Erreur 1

Body: 

Erreur 1 : choisir une méthode push plutôt que "call" entre clients et serveurs

Quand vous développez une application client <> serveur, cela peut être plein de choses (apps mobiles, trading..), vous avez le choix entre 3 approches :

1 - Soit le client (c'est à dire l'usager au final) appelle le serveur et vient y chercher les infos dont il a besoin. C'est le CALL
2 - Soit le serveur "balaie" les clients en leur envoyant les informations.C'est le PUSH
3 - Soit le client et le serveur ouvre une connexion et "discutent" en permanence. Ce sont les sockets typiquement avec les protocoles diverses et variés qui maintiennent une connexion client <> serveur ouverte en permanence.

Le point 1 et 3 sont à discuter au cas par cas en fonction des nécessités de réponse et si l'ordre des réponses attendues à une importance ou pas.

Mais le point 2 est une erreur dans 100% des cas et je vais expliquer pourquoi.

L'option "de push" du serveur vers les clients comme le font par exemple beaucoup d'entreprises mirror trading ou de social trading en recevant "un ordre" et en le poussant à tous les autres clients est une mauvaise option car :

- Elle entraine une course dans la rapidité du serveur. Au fur et à mesure que vous avez de plus en plus de clients, votre serveur doit balayer de plus en plus vite. Ce qui paraissait être une bonne idée en terme de performance (on n'est pas assailli de demandes clients en permance "non utiles") devient un cauchemard de technicien car :

1 - Vous perdez automatiquement en rapidité et des déphasages non anticipés vont se produire c'est à dire qu'entre le moment où l'ordre est reçu par le serveur central et le moment où l'ordre est récupéré par le client distant, le nombre de millisecondes, plus de secondes, voir de minutes augmente de manière exponentielle avec le nombre de clients. En terme de trading, c'est une catastrophe même si vous avez les serveurs les plus rapides.

2 - Le serveur devient le maillon faible, un ralentissement du serveur va entrainer une mise "en queue" de tous les clients de manière généralisée alors que dans l'option 1 ou 3, certains clients seront ralentis et d'autres non en fonction de ce qu'ils demandent. L'option 2 pénalise donc de la même manière tous les clients....

Normalement les ingénieurs systémes et développeurs qui ont pris l'option "2" vont alors sortir leur carte joker qui est la parallélisation des ordres d'envoi. En gros plusieurs batchs lancent ensemble des sequences d'ordre de manière parallèlle.

Là encore c'est l'augmentation des ressources serveurs et applicatifs qui est la solution à ce problème d'engorgement. De plus il y a bien toujours du séquentiel à l'intérieur de la parallélisation. Pour qu'une parallélisation soit payante jusqu'au bout il faut tout parralléliser de manière massive en packet "de 1" donc retourner dans une option 1 "non étudiée".

Le deuxième effet Kiss Cool du choix de l'option 2 est que les développeurs ont souvent à modifier leur code pour paralléliser correctement surtout si des actions sont imbriquées avec un ordre qui ne peut pas bouger. On ajoute donc des strates de développement rapide et pas toujours très bien codés car codés dans l'urgence.

Le point 2 - le PUSH serveur - est une option qui doit donc être proscrite dès que vous envisagez une augmentation du nombre de clients et que vous ne pourrez pas la maitriser. Typiquement si vous mettez une APP Sur l'APP Store, cela sera le cas car c'est exactement ce que vous cherchez.