Construire une architecture multi-bot
Pourquoi j'ai fini par m'éloigner d'un bot de trading unique pour penser en termes de systèmes indépendants.
Quand j'ai commencé à construire Oblivion, l'architecture semblait évidente : une plateforme, un moteur de trading, un système responsable de tout.
À l'époque, cette approche me semblait parfaitement raisonnable. Après tout, beaucoup d'applications de trading fonctionnent de cette manière. Un seul processus reçoit les données de marché, prend des décisions et exécute les trades.
Mais plus je travaillais sur le projet, plus les limites commençaient à apparaître.
Le problème d'un grand système unique
Un bot unique est facile à comprendre, facile à déployer et facile à visualiser. Mais la complexité augmente étonnamment vite.
Gérer un actif est relativement simple. Gérer dix actifs n'est pas simplement dix fois plus difficile. De nouvelles questions commencent à apparaître.
Comment les positions interagissent-elles ? Comment le capital doit-il être réparti ? Que se passe-t-il si un actif devient extrêmement volatil pendant qu'un autre reste inactif ? Comment isoler les échecs ?
À mesure que les responsabilités s'accumulaient dans le même processus, l'architecture devenait de plus en plus difficile à raisonner.
L'isolation crée de la clarté
Une prise de conscience a changé ma manière de penser le problème : et si chaque paire de trading se comportait comme son propre système indépendant ?
Au lieu d'une énorme entité qui tente de tout gérer simultanément, chaque marché pourrait avoir sa propre logique, son propre état et son propre cycle de vie.
Cette idée a immédiatement simplifié beaucoup de problèmes. Un échec affectant une paire n'aurait pas nécessairement d'impact sur les autres. L'allocation du capital devenait plus facile à comprendre, le monitoring devenait plus granulaire et le debugging devenait beaucoup moins pénible.
Surtout, le système devenait plus facile à scaler.
Penser en systèmes plutôt qu'en trades
À un moment donné, j'ai arrêté de penser principalement aux trades. J'ai commencé à penser en systèmes.
Un trade dure quelques minutes, quelques heures ou quelques jours. Un système peut fonctionner pendant des années.
Les décisions de design les plus importantes concernent rarement une seule position. Elles concernent la manière dont la plateforme se comporte après des milliers de décisions.
L'architecture devait supporter cette réalité.
La complexité ne disparaît pas
Construire une architecture multi-bot ne supprime pas la complexité. Elle la déplace.
Au lieu de gérer la complexité à l'intérieur d'un énorme processus, on gère les interactions entre des composants plus petits.
La coordination devient importante. La visibilité devient importante. La cohérence devient importante. Le défi passe de l'exécution à l'orchestration.
Mais ce compromis me semblait valable.
Avec le recul
Aujourd'hui, j'ai du mal à imaginer Oblivion construit autour d'un seul bot de trading monolithique.
La plateforme a pu grandir parce que l'architecture lui permettait de grandir.
Les fonctionnalités sont devenues plus faciles à ajouter. Les échecs sont devenus plus faciles à isoler. Le système est devenu plus facile à comprendre.
Et peut-être plus important encore, l'architecture est restée alignée avec l'objectif initial : construire quelque chose capable de fonctionner de manière fiable sur le long terme.
Plus le temps passe, plus je suis convaincu que les décisions d'architecture comptent souvent davantage que les décisions de stratégie.
Une bonne architecture ne garantit pas le succès. Mais une mauvaise architecture finit presque toujours par créer des problèmes.