État persistant plutôt que mémoire du processus
Les données de positions consignées et les transactions de base de données offrent un parcours de reprise plus clair que le stockage de l’état critique uniquement dans un processus actif.
Projet d’ingénierie
Refonte d’un système de trading centrée sur l’état persistant des positions, les données Bybit en temps réel, le traitement des signaux par webhook et un tableau de bord opérationnel React.

Portée de la mise en œuvre
La refonte a remplacé la gestion des positions en mémoire par un état stocké dans PostgreSQL afin que les positions actives et les détails des ordres de protection survivent au redémarrage et puissent être examinés dans un modèle opérationnel plus fiable.
La couche serveur utilise des services FastAPI pour l’authentification, les paramètres, la réception des signaux et la gestion des positions. Un client WebSocket dédié reçoit les mises à jour de marché et d’exécution privées, tandis que l’API REST soutient les actions d’ordres.
L’interface a été réorganisée autour de React, TypeScript, Zustand, TanStack Query et d’un système de composants pour les paramètres, la visibilité des états et les mises à jour du tableau de bord.
Choix d’ingénierie
Les données de positions consignées et les transactions de base de données offrent un parcours de reprise plus clair que le stockage de l’état critique uniquement dans un processus actif.
Les flux publics de marché et privés de compte ou d’exécution sont traités comme des sources explicites pour différentes parties du flux de trading.
Des limites claires pour les messages d’API et de WebSocket facilitent la maintenance des mises à jour et des responsabilités du service de trading.
Limites actuelles