Le carnet d'ordres se fige quand le marché s'emballe ? Comment réparer le flux de données de marché et qui peut le faire

Si le carnet d'ordres de vos écrans de trading se fige, saute ou affiche des prix impossibles dans un marché agité, le défaut se trouve en général à l'un de trois endroits. Des mises à jour se perdent là où arrive le flux de la bourse, le carnet est mal assemblé, ou il atteint trop lentement des centaines d'écrans. Mesurez votre heure la plus chargée avant d'engager qui que ce soit, puis testez chaque société que vous envisagez sur un enregistrement de cette journée.

À quoi ressemble à l'écran un flux de données de marché défaillant ?

Cela se produit aux moments les plus chargés, comme une annonce de banque centrale ou l'ouverture du marché. Le carnet à l'écran s'arrête une seconde ou deux, puis saute. Des ordres annulés restent visibles. Parfois, le prix le plus élevé proposé par un acheteur dépasse le prix le plus bas demandé par un vendeur : on parle alors de carnet croisé. Sur une seule bourse, en dehors des enchères d'ouverture et de clôture, de tels ordres s'exécuteraient aussitôt. Un carnet croisé pour une seule bourse sur votre écran signifie donc que votre copie de ce carnet est fausse.

Le support reçoit alors les captures d'écran de deux traders qui voient des carnets différents pour le même instrument. Ou un trader conteste le prix auquel un ordre a été exécuté, parce que l'écran en affichait un autre.

Pourquoi des mises à jour se perdent-elles ou arrivent-elles dans le désordre ?

Le flux du carnet d'ordres d'une bourse est une suite de petits changements : un ordre ajouté, un ordre annulé, une transaction. Votre système part d'une copie complète du carnet, appelée instantané (snapshot), et applique les changements dans l'ordre. Chaque changement est numéroté, ce qui permet de repérer celui qui manque. La spécification de Nasdaq pour son flux TotalView-ITCH 5.0 indique que le flux « se compose d'une série de messages séquencés », c'est-à-dire numérotés dans l'ordre.

Dans un marché agité, le flux de changements augmente brusquement. Certains se perdent en route ou dans vos propres serveurs, et d'autres arrivent dans le désordre. Si le système ne voit pas le trou, il applique tout ce qui arrive et affiche un carnet qui ne correspond plus à celui de la bourse. S'il remarque le trou mais met plusieurs secondes à se rétablir, l'écran reste figé.

Les bourses s'attendent à ce que leurs clients perdent des mises à jour. La documentation de CME Group pour son flux MDP 3.0 indique qu'après un trou, « il faut partir du principe que tous les carnets tenus dans le système du client peuvent ne plus refléter l'état correct le plus récent ».

À quel endroit du système le flux casse-t-il ?

Il y a trois endroits, et chacun demande sa propre correction. Les ingénieurs appellent le troisième le fan-out, parce qu'un seul flux de mises à jour se déploie en éventail vers de nombreux écrans. L'article technique dont le lien figure plus haut les détaille tous les trois.

Le premier endroit est la réception, là où arrive le flux de la bourse. Certaines bourses offrent des moyens de récupérer les données perdues. L'un des protocoles de diffusion de Nasdaq, MoldUDP64, permet aux récepteurs de « détecter les paquets manqués et de les redemander ». CME envoie son flux en double, sur des lignes appelées A et B, et diffuse un flux distinct d'instantanés pour remettre les carnets à jour. Rien de tout cela n'aide si votre système ne remarque pas le trou.

Ensuite, le carnet est assemblé, et le danger est ici un changement appliqué deux fois, dans le désordre ou par-dessus le mauvais instantané. Binance, une bourse crypto, détaille dans son guide les étapes exactes pour raccorder un instantané au flux en direct. Un carnet construit sans elles affiche toujours des prix et a l'air correct, mais les prix sont faux.

Vient enfin le fan-out, où le carnet part vers des centaines de sessions de traders, une par écran connecté. Un trader sur une connexion mobile faible, ou un terminal qui s'est bloqué, lit les mises à jour lentement. Si le serveur attend cette session, toutes les autres attendent aussi. Laisser grossir sans limite les mises à jour en attente pour cette session ne vaut pas mieux, car le serveur manque de mémoire et tombe en panne pour tout le monde.

Dans un système bien conçu, le serveur met les mises à jour en ordre une seule fois et envoie le même résultat à chaque session. Une session qui prend du retard reçoit soit l'image la plus récente du carnet, en sautant les étapes intermédiaires, soit une déconnexion dont le serveur indique la raison, et l'écran se reconnecte alors avec une copie à jour. Un flux peut casser à plusieurs endroits à la fois.

Que mesurer avant d'engager qui que ce soit ?

Prenez votre heure la plus chargée du mois dernier et relevez-en les chiffres suivants :

• Trous : combien de fois le système a trouvé un numéro de mise à jour manquant sur chaque flux de bourse. Si le système ne les compte pas, c'est votre premier constat
• Temps de reprise : combien de temps a pris chaque reconstruction, et ce que les traders voyaient pendant ce temps
• Délai : le temps entre l'horodatage de la bourse sur un message et le moment où la mise à jour quitte votre serveur vers le trader, et, sur quelques terminaux de test, jusqu'à l'écran. Prenez la médiane et le 99e percentile, c'est-à-dire le temps sous lequel restent 99 mises à jour sur 100. Synchronisez les horloges de vos serveurs sur une source de temps précise, sinon les chiffres ne veulent rien dire
• Sessions : combien ont pris du retard, de combien, et combien ont été déconnectées, avec la raison de chaque déconnexion

Enregistrez ensuite le flux brut d'une journée chargée exactement tel qu'il est arrivé, avec l'heure d'arrivée de chaque paquet. Rejouer cet enregistrement à vitesse réelle et plus vite, c'est le test que vous faites passer à chaque société de votre liste et que vous répétez après chaque correction.

Corriger notre propre feed handler, en acheter un ou reconstruire le fan-out ?

Le logiciel qui reçoit le flux d'une bourse et tient le carnet s'appelle un feed handler. Vous avez trois voies, et vos mesures devraient en désigner une. Les deux dernières peuvent se combiner.

Quand la correction de notre propre feed handler se justifie-t-elle ?

Corrigez le feed handler que vous avez quand les mesures désignent un défaut clair, comme des trous qui passent inaperçus ou une reconstruction lente, et que les personnes qui connaissent le code sont toujours là.

• Quand c'est le bon choix : un défaut que vous savez nommer et une conception qui, pour le reste, fonctionne
• Ce que vous payez : le temps d'ingénierie et un banc de test qui rejoue vos enregistrements
• À qui appartient le code : à vous
• La limite : une correction à la réception n'aide pas si le problème se situe dans l'envoi du carnet vers les écrans

Quand faut-il acheter un feed handler ou un flux managé ?

Un feed handler tout fait est un logiciel sous licence qui se connecte à une bourse, repère les trous et remet à votre système un carnet correct et à jour. Un flux managé va plus loin : un fournisseur de données de marché se connecte aux bourses, et vous recevez de lui un seul flux dans un seul format.

• Quand c'est le bon choix : de nombreuses bourses aux formats standard, et aucune envie de suivre chaque changement que chaque bourse apporte à son flux
• Ce que vous payez : la licence et le travail de connexion du produit à votre système. Les frais de données et les conditions de licence propres aux bourses s'appliquent en général toujours, quel que soit celui qui livre les données
• Ce qui reste à votre charge : acheminer le carnet vers des centaines d'écrans de traders et gérer les sessions lentes
• À qui appartient le code : le produit appartient à l'éditeur. L'intégration et tout ce qui vient après vous appartiennent

Quand faut-il engager une équipe pour reconstruire le fan-out ?

Reconstruisez la couche qui envoie les données aux traders quand la réception fonctionne mais que les problèmes persistent. Les traders voient toujours des carnets différents, une session lente ralentit toutes les autres, ou vous prévoyez de servir beaucoup plus de sessions qu'aujourd'hui.

• Quand c'est le bon choix : le délai augmente entre vos serveurs et les écrans, pas entre la bourse et vos serveurs
• Ce que vous payez : le temps d'ingénierie et de test, puis les personnes qui exploitent le système après le lancement
• À qui appartient le code : à vous, si le contrat le prévoit

Comment vérifier une société avant de l'engager ?

Soumettez chaque société de votre liste aux cinq mêmes tests :

• Un rejeu de votre enregistrement, à vitesse réelle et plusieurs fois plus vite, à travers ce que la société livre ou présente en démonstration. Comparez ses trous, ses reconstructions, ses temps de reprise et ses délais avec ceux de votre système actuel
• Comment le système repère un trou. Une bonne réponse dit que le système n'applique un changement que si son numéro est le suivant attendu. S'il manque un numéro, le système attend brièvement, puis redemande le changement ou reconstruit le carnet. D'ici là, il marque le carnet comme périmé. Demandez ce que voient les traders pendant ce temps
• Ce qui arrive avec un trader lent. Demandez à la société de ralentir volontairement une session pendant le rejeu. Les délais des autres sessions ne doivent pas changer
• Comment la société mesure le délai : de quel horodatage jusqu'à quel point, à quel percentile, sous quelle charge et sur quel matériel, et comment les horloges sont synchronisées
• À qui appartient le code, et à quelles conditions vous utilisez les parties que la société conserve comme les siennes

Quels sont les signaux d'alerte ?

• « Nous allons ajouter des serveurs » comme première réponse, avant que quiconque ait vu vos mesures
• « Nous utilisons une connexion fiable, donc rien ne se perd. » Binance envoie ses mises à jour par WebSocket, un type de connexion qui ne perd pas de données en transit, et son guide explique pourtant aux clients quoi faire quand des événements sont sautés

Où se situe amBrain ?

amBrain construit des infrastructures de trading algorithmique : exécution des ordres, données de marché et contrôles de risque pre-trade.

Une ligne du site web d'amBrain indique : « Développement de terminaux de trading, systèmes de gestion des ordres et intégration des places de marché via le protocole FIX. »

amBrain diagnostique les systèmes lents dans le trading et l'ad tech : la plateforme en fonctionnement est mesurée de bout en bout, et le rapport indique où passe le temps.

amBrain développe des logiciels depuis 2019. Elle décrit son équipe en une ligne : « Une équipe pouvant aller jusqu'à 40 personnes, dont environ 75 % de seniors. » Elle travaille en trois formats : la prestation complète, une équipe dédiée ou des ingénieurs intégrés à votre équipe. Le client conserve la pleine propriété du produit et du code, à l'exception des composants réutilisables d'amBrain.

Cet article n'est pas une étude de cas et ne décrit aucun travail réalisé pour un client. Il ne cite aucun chiffre de latence pour les systèmes qu'amBrain a construits, et aucun prix ni délai.

Si amBrain figure sur votre liste restreinte, posez-lui les cinq mêmes questions qu'à toutes les autres sociétés, et faites de votre enregistrement le critère de réussite de tout travail convenu.

Questions fréquentes

• Plus de serveurs régleront-ils le problème ? Pas à eux seuls. Si le système applique les changements dans le désordre ou attend sa session la plus lente, davantage de serveurs reproduisent le même défaut. Ajoutez des serveurs quand les mesures montrent que les serveurs actuels manquent de capacité
• Peut-on regrouper les mises à jour et en envoyer moins ? Pour le carnet d'ordres, oui. Les ingénieurs appellent cela la conflation, et certaines bourses le font elles-mêmes. La documentation de Binance fixe la vitesse de mise à jour de son flux spot des changements du carnet d'ordres à 1000 ms ou 100 ms. Dites aux traders que le flux montre l'image la plus récente, pas chaque étape. Ne regroupez pas les transactions ni les confirmations d'ordres, car en perdre une fausse l'historique des transactions
• Faut-il le réécrire en Rust ou en C++ ? Pas forcément. Des trous qui passent inaperçus et un serveur qui attend sa session la plus lente sont des défauts de conception qu'un nouveau langage ne supprime pas. Rust et C++ n'ont pas de garbage collector, le nettoyage automatique de la mémoire qui peut mettre en pause un programme écrit dans un langage comme Java ou Go. Cela aide dans les parties du système qui traitent chaque mise à jour. Quel que soit le langage, demandez le délai mesuré au pic
• Combien de temps prend une correction ? Cela dépend de l'endroit où se trouve le défaut et du nombre de bourses et de sessions que vous avez. Demandez à chaque société de chiffrer et de planifier une première phase qui couvre les mesures et un banc de test qui rejoue votre enregistrement. Utilisez les cinq tests ci-dessus comme critères de réussite