La gestion d'état dans les systèmes de trading longue durée

L'une des premières choses que le trading automatisé m'a apprises, c'est que les décisions existent rarement de manière isolée.

Un système ne peut pas simplement regarder la situation actuelle et oublier tout ce qui s'est passé avant. Il a besoin de contexte : ce qu'il a déjà fait, ce qui est actif maintenant et quelles hypothèses restent valides.

Ce contexte, c'est l'état.

Et dans un système de trading longue durée, l'état n'est pas un détail. C'est une partie de la mémoire du produit.

Un système de trading a une mémoire

Une action automatisée crée immédiatement de nouvelles informations.

Un ordre peut être en attente, terminé, rejeté ou attendre qu'une autre partie du système réagisse. La décision suivante ne peut pas ignorer cette histoire sans risque.

Un système longue durée se comporte donc moins comme une collection de fonctions indépendantes que comme un processus continu avec de la mémoire.

Cela semble évident jusqu'au moment où l'application redémarre.

Les redémarrages ne réinitialisent pas la réalité

Le logiciel finit toujours par redémarrer, volontairement ou non.

Le monde extérieur, lui, ne redémarre pas avec l'application. Les ordres existants, les décisions précédentes, les soldes et les positions ouvertes comptent toujours. Un système robuste doit retrouver sa compréhension de la réalité au lieu de supposer qu'il repart de zéro.

C'est là que les raccourcis deviennent dangereux.

Si la plateforme ne sait pas ce qui s'est passé avant le redémarrage, elle peut dupliquer du travail, ignorer une exposition active ou prendre des décisions à partir d'informations incomplètes.

Les systèmes distribués compliquent le problème

Le défi augmente quand les responsabilités sont réparties entre plusieurs composants.

Différentes parties d'une plateforme peuvent observer les événements à des moments légèrement différents. Des messages peuvent arriver plus tard que prévu. Un composant peut redémarrer pendant qu'un autre continue normalement.

L'objectif n'est pas de rendre tout instantané.

L'objectif est de garder l'état global suffisamment cohérent pour que des informations incomplètes ne créent pas des hypothèses dangereuses.

L'état doit être conçu explicitement

La gestion d'état devient fragile quand elle est traitée comme quelque chose qui apparaît simplement en cours de route.

Certaines informations doivent être stockées. Certaines doivent être recalculées. Certaines doivent être confirmées auprès d'une source externe avant que le système puisse leur faire confiance.

Ces décisions façonnent la façon dont la plateforme se comporte sous pression.

Pour Oblivion, cela a changé ma manière de penser la persistance, la récupération et l'observabilité. La question n'était pas seulement ce que le système devait faire quand tout était normal. C'était aussi ce que le système devait se rappeler quand les conditions normales disparaissaient.

Avec le recul

La gestion d'état n'est pas le genre de fonctionnalité que les utilisateurs remarquent normalement.

Idéalement, ils n'ont jamais besoin d'y penser. Mais si un système longue durée perd son contexte, l'automatisation devient rapidement de la devinette.

Le logiciel financier est l'un des derniers endroits où je veux que la plateforme devine.